Wireguard client

No. IIUC this is quite buggy and might even void warranty?

Or is it somewhat stable now and easier to install?

It will not void the warranty. And while not perfect yet I’ve been running it for months with only a few problems.

as in – if things break “There is a downside to this: your system may be rendered unbootable and you’d need to open the Vero and short two pins on the mainboard to recover it if this is the case.

But seems that that thread also says testing is finished/closed.

So how do I proceed to install 4.9? apt install linux-image-4.9.0-12-arm64 ; reboot ?

Read the first post in the testing thread. [TESTING] Linux 4.9 kernel and improved video stack for Vero 4K / 4K +

1 Like

Cool – that worked:

# uname -a
Linux osmc 4.9.113-16-osmc #1 SMP PREEMPT Thu Apr 16 18:53:29 UTC 2020 aarch64 GNU/Linux

However this an issue with the headers:

root@osmc:/lib/modules# dpkg-reconfigure wireguard-dkms

------------------------------
Deleting module version: 0.0.20200318
completely from the DKMS tree.
------------------------------
Done.
Loading new wireguard-0.0.20200318 DKMS files...
Building for 4.9.113-16-osmc
Module build for kernel 4.9.113-16-osmc was skipped since the
kernel headers for this kernel does not seem to be installed.

I think you’re a bit stuck, I’m afraid.

As noted above, kernel 3.14 probably doesn’t support wireguard. I think the “kernel headers for this kernel does not seem to be installed.” message you saw might have been because of a missing symbolic link.

I’ve checked the OSMC repo and can’t see any headers for the 4.9 kernel.

One other point. Currently DKMS doesn’t wotk well with OSMC due to a few longstanding issues with the kernel headers.

So /lib/modules/4.9.113-16-osmc/build doesn’t exist and indeed there’s no 4.9 under /usr/src/

And indeed that the headers are missing for that particular kernel:

root@osmc:/lib/modules/4.9.113-16-osmc# apt search 4.9 | grep header

WARNING: apt-real does not have a stable CLI interface. Use with caution in scripts.

linux-headers-4.9.0-12-all - All header files for Linux 4.9 (meta-package)
linux-headers-4.9.0-12-all-arm64 - All header files for Linux 4.9 (meta-package)
linux-headers-4.9.0-12-all-armhf - All header files for Linux 4.9 (meta-package)
linux-headers-4.9.0-12-arm64 - Header files for Linux 4.9.0-12-arm64
linux-headers-4.9.0-12-armmp - Header files for Linux 4.9.0-12-armmp
linux-headers-4.9.0-12-armmp-lpae - Header files for Linux 4.9.0-12-armmp-lpae
linux-headers-4.9.0-12-common - Common header files for Linux 4.9.0-12
linux-headers-4.9.0-12-common-rt - Common header files for Linux 4.9.0-12-rt
linux-headers-4.9.0-11-all - All header files for Linux 4.9 (meta-package)
linux-headers-4.9.0-11-all-arm64 - All header files for Linux 4.9 (meta-package)
linux-headers-4.9.0-11-all-armhf - All header files for Linux 4.9 (meta-package)
linux-headers-4.9.0-11-arm64 - Header files for Linux 4.9.0-11-arm64
linux-headers-4.9.0-11-armmp - Header files for Linux 4.9.0-11-armmp
linux-headers-4.9.0-11-armmp-lpae - Header files for Linux 4.9.0-11-armmp-lpae
linux-headers-4.9.0-11-common - Common header files for Linux 4.9.0-11
linux-headers-4.9.0-11-common-rt - Common header files for Linux 4.9.0-11-rt

Is there any chance this will be fixed?

I am still working on a solution for the headers issue.

I can backport Wireguard for you if you are willing to test.

1 Like

I’ll gladly test this. Using Wireguard is the easiest way forward for me to route certain but not all traffic through a certain endpoint.

ill also test it when i get the time. Damn quarantined kids ;D

I would be eager to test this.

I’ve added Wireguard support to our kernel.
It will be in the next 4.9 build.

4 Likes

Perfect – this actually works:

root@osmc:/etc/wireguard# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.200.200.52/24 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -4 route add 52.0.0.0/11 dev wg0

root@osmc:/etc/wireguard# ping 10.200.200.1 -c 3
PING 10.200.200.1 (10.200.200.1): 56 data bytes
64 bytes from 10.200.200.1: seq=0 ttl=64 time=175.980 ms
64 bytes from 10.200.200.1: seq=1 ttl=64 time=176.109 ms
64 bytes from 10.200.200.1: seq=2 ttl=64 time=175.955 ms

--- 10.200.200.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 175.955/176.014/176.109 ms

Thanks!

1 Like

Great, thanks for testing.

Hi Sam,

Thanks a lot for adding wireguard module to the last build !
I confirm it works like a charm.

@sam_nazarko is it possible iptables connmark target is missing from the kernel?
WireGuard works fine, until I try to route all traffic through WG. It crashes on an iptables error. WireGuard dev thinks it’s connmark.

It’s there in kernel 3.14.29-157.

Looking through the WireGuard documentation I see at least five different method described.

That’s a bit short on detail. Please describe in more detail what you are doing, show all error messages, and provide full logs (grab-logs -A).

1 Like

I’ve checked this.

We have:

# Xtables combined modules
#
CONFIG_NETFILTER_XT_MARK=y
CONFIG_NETFILTER_XT_CONNMARK=y

Here is our complete configuration: https://paste.osmc.tv/raw/jugefiwona

Sam

1 Like

Cheers.

Yes I believe there are several ways of routing traffic, but ideally I’d want to use wg-quick. The error happens at this line in the script: echo -n "$restore" | cmd $iptables-restore -n under add_default(). Note that it’s only a problem when redirecting all traffic through WireGuard (AllowedIPs = 0.0.0.0/0).

So the error was pretty non-descriptive: something along the lines of iptables-restore: error on line 3 and would crash wg-quick.

Comparing a Debian (amd64) I’ve noticed that the following packages were only partly installed: iptables libip6tc0 libiptc0 libjansson4 libnetfilter-conntrack3 libnfnetlink0 libnftables0 libnftnl11 nftables

I tried to install them one by one.

Installing nftables the error goes away but the tunnel remains offline.

It seems like libnftables0 doesn’t exist, but similar package exists named libnftables1. Installing that one causes issues though:

root@osmc:/home/osmc# apt install libnftables1
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libnftables1 : Depends: libc6 (>= 2.28) but 2.24-11+deb9u4 is to be installed
                Depends: libxtables12 (>= 1.6.1) but 1.6.0+snapshot20161117-6 is to be installed
E: Unable to correct problems, you have held broken packages.

Logs are at https://paste.osmc.tv/catirumufu

One thing that strikes me immediately is that wg-quick is part of the wireguard-tools package, which is only available in buster-backports (and unstable). Since OSMC is still on Debian stretch, such unmet dependencies are very likely to occur.

I’ll take a more in-depth look this evening.