Has anybody tried to install Wireguard?

I don’t know if Wireguard works with DKMS.
It still seems quite fresh; so I’d be surprised if there are yet significant efforts to support backports

Hi Sam, The wireguard package depends on wireguard-dkms which in turn depends on dkms itself. The wireguard package looks like it’s just the dependencies and changelog. The code for the kernel module is in wireguard-dkms.

I’m running wireguard on an Ubuntu 14.04 server at home, although that’s through the PPA, and I don’t remember whether it compiled a kernel module or just installed something pre-compiled.

If I create a build environment, does that mean I can try to create a deb and upload it somewhere?

You already have a build environment now.
A Deb would be to package a finished module; which you don’t have yet.

Try run find to see if you do have sys/socket.h
I seem to remember perpetual header problems for ARM architecture with make-kpkg but make deb-pkg still isn’t suitable yet.

Sam

Yeah there is one sys/socket.h as follows:

$ find / -name socket.h | grep sys/socket.h
/usr/include/arm-linux-gnueabihf/sys/socket.h

There are other directories of header files there. So I created symlinks to /usr/include but it didn’t help.

I ran a make -n in the module build directory and I can see that -nostdinc is in the compiler options. There’s only one directory it puts on its search path using -isystem and then adds a bunch of relative dirs using -I:

 -nostdinc
 -isystem /usr/lib/gcc/arm-linux-gnueabihf/6/include
 -I./arch/arm/include
 -I./arch/arm/include/generated
 -I./include
 -I./arch/arm/include/uapi
 -I./arch/arm/include/generated/uapi
 -I./include/uapi
 -I./include/generated/uapi

I was thinking that there’s something to this, however I compared this to a working Raspbian build of Wireguard I have, and it’s the exact same compiler options. The sys/socket.h header file is in the same place too.

So now I’m at a loss.

Maybe make is wrapped / layered.
Try export your CFLAGS

The error you’re seeing is very similar to the one in this post: Mantistek WA150 - #7 by skdauser, which I can reproduce.

The Mantistek WA150 code does not produce the error on Raspbian Jessie or Debian stretch (amd64) (I’ll look at Raspbian stretch when I have a bit more time).

So far, it looks like there might be a problem with the OSMC headers package.

Update: The problem does not occur with Raspbian stretch.

I worked out that the include directories are relative to the directory in which make is running (duh!). So on my Raspbian, that’s /lib/modules/4.14.79-v7+/build.

In my Raspbian build environment, I traced the sequence of includes from the error in the make.log and there’s a difference. The difference is that in Raspbian nf_conntrack_tuple_common.h comes from ./include/uapi/linux/netfilter/nf_conntrack_tuple_common.h instead of ./include/linux/netfilter/nf_conntrack_tuple_common.h as shown in the error message from the OSMC build environment.

When Raspbian gets to ./include/linux/netfilter.h it then includes ./include/uapi/linux/if.h instead of OSMC’s ./include/linux/if.h. The Raspbian file ./include/uapi/linux/if.h includes <linux/socket.h> rather than <sys/socket.h>.

A quick google tells me that the uapi directory is for the user-space API headers. Is this useful information?

Edited 2019-01-10: Made it clearer which is Raspbian vs OSMC.

1 Like

I had a look at the osmc build script on github but I’m not that familiar with kernel build processes. Is the problem somehow related to the code that disassembles the kernel headers package here?

Shouldn’t be.
IIRC, make-kpkg doesn’t handle UAPI for arm in the same way it does for other platforms.

I’ve not managed to find an example of ./include/linux/if.h: on the 4.14.78 kernel image from kernel.org – and, as you already mentioned, it doesn’t appear in the Raspbian 4.14.79-v7+ headers. If @sam_nazarko can tell us the source of the kernel headers he’s using, that would be a step forward.

The kernel headers come from the tree itself.

Well, the build.sh code downloads a compressed tar file from kernel.org.

SOURCE_LINUX="https://www.kernel.org/pub/linux/kernel/v${MAJOR}.x/linux-${DL_VERSION}.tar.xz"

Are you referring to this file? That’s the “clean” Linux source tree without any distribution-related changes.

A correction to my last post: The file if.h does include <sys/socket.h> if __KERNEL__ is not defined:

#ifndef __KERNEL__
#include <sys/socket.h>			/* for struct sockaddr.		*/
#endif

For the Rasbian build, __KERNEL__ must be getting defined somewhere. I haven’t checked how this is getting defined - compiler flags or other explicit #define - but either way it seems strange that the OSMC header file(s) are ending up in different directories to what’s on kernel.org.

Hi there,

I’m also very interested in getting Wireguard running on osmc. I’m also stuck with the same error messages as @graza has mentioned above (sys/socket.h: No such file or directory). Tried creating different symbolic links from the existing socket.h files to probably used folders during make process, but still the socket.h can’t be found.

So if someone has hints or ideas how to sole this issue, I would be really grateful.

I’ve tracked down what I believe to be the source of the problem to the use of the make headers_install command in the kernel-osmc build. There’s a shell script at ./src/linux-4.14.78/scripts/headers_install.sh that contains this piece of code:

echo "Usage: headers_install.sh OUTDIR SRCDIR [FILES...]"
echo
echo "Prepares kernel header files for use by user space, by removing"
echo "all compiler.h definitions and #includes, removing any"
echo "#ifdef __KERNEL__ sections, and putting __underscores__ around"
echo "asm/inline/volatile keywords."
echo
echo "OUTDIR: directory to write each userspace header FILE to."
echo "SRCDIR: source directory where files are picked."
echo "FILES:  list of header files to operate on."

It take the uapi headers and changes code such as:

#ifndef __KERNEL__ 
#include <sys/socket.h>     /* for struct sockaddr. */ 
#endif

to

#include <sys/socket.h>			/* for struct sockaddr.		*/

thereby losing the #ifndef logic. This doesn’t happen on Raspbian – and I don’t understand why this logic is being stripped out. Perhaps @sam_nazarko can explain why it’s done this way.

It looks like the altered files are then copied from ./include/linux/uapi to ./include/linux, which is why you see two different versions of (for example) if.h. It’s not simply a matter of deleting everything from ./include/linux since it wasn’t originally empty.

Still exploring.

Sam

As a workaround for now, you can remove all dodgy headers in the include/linux directory, then re-copy from the kernel.org source:

sudo rm -r /usr/src/rbp2-headers-4.14.78-4-osmc/include/linux/*
sudo cp -ar ./linux-4.14.78/include/linux/* /usr/src/rbp2-headers-4.14.78-4-osmc/include/linux/

The WireGuard make sails through – though, in my case, I needed to add the package libmnl-dev.

osmc@osmc:~$ modinfo wireguard
filename:       /lib/modules/4.14.78-4-osmc/extra/wireguard.ko
alias:          net-pf-16-proto-16-family-wireguard
alias:          rtnl-link-wireguard
version:        0.0.20181218-13-g83a9318
author:         Jason A. Donenfeld <Jason@zx2c4.com>
description:    WireGuard secure network tunnel
license:        GPL v2
srcversion:     2D91A3D8F670D97E4F9BE3C
depends:        ipv6,udp_tunnel,ip6_udp_tunnel
name:           wireguard
vermagic:       4.14.78-4-osmc SMP preempt mod_unload modversions ARMv7 p2v8 

As for getting it to work, I’ll leave that to you!

This is still an outstanding problem when producing armhf packages.
I think make-kpkg is causing this issue.

I thought I’d fixed this some time ago but will need to revisit as we should be shipping everything needed to build modules when the header packages are installed.

@dillthedog Thanks, I’ll try that and report back.

I created a VirtualBox VM and checked out the OSMC github repo to see if I can understand what’s going on with the packaging. While it was compiling everything for the rbpi2 target, I looked at the source tree and the headers are there as per the content of kernel.org.

I took quite a while to compile everything - maybe 28 hours or more? Not sure if that’s normal or if it would benefit from having more virtual CPUs in the VM?

That’s quite a long time; I’d assign some more CPUs if you can.
You can also build on the Pi itself.

Sam