Update wireguard package?

FROM fedora:25

ENV SDK OpenWrt-SDK-mvebu_gcc-4.8-linaro_musl-1.1.15_eabi.Linux-x86_64

RUN dnf upgrade -y &&
dnf install -y git wget bzip2 findutils ccache gcc which &&
wget --no-check-certificate https://api.turris.cz/openwrt-repo/omnia/$SDK.tar.bz2 --directory-prefix=/tmp &&
mkdir -p /turris/ipk &&
tar xvjf /tmp/$SDK.tar.bz2 --directory=/turris &&
rm -rf /tmp/$SDK.tar.bz2 &&
git clone https://github.com/openwrt/packages.git /turris/openwrt-packages/ &&
cp -r /turris/openwrt-packages/net/wireguard/ /turris/$SDK/package/ &&
export PATH=$PATH:/turris/$SDK/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-4.8-linaro_musl-1.1.15_eabi/bin &&
echo -e “SECTIONS {\n\t.core.plt : { BYTE(0) }\n\t.init.plt : { BYTE(0) }\n}” > /turris/$SDK/build_dir/target-arm_cortex-a9+vfpv3_musl-1.1.15_eabi/linux-mvebu/linux-4.4.51/arch/arm/kernel/module.lds &&
make CXX=arm-openwrt-linux-g++ LD=arm-openwrt-linux-ld V=s -C /turris/$SDK &&
cp /turris/$SDK/bin/mvebu-musl/packages/base/*.ipk /turris/ipk/

CMD [“cp”,"-r","/turris/ipk/","/tmp"]

Put this in a file called “Dockerfile”
**I would indent the lines between RUN and CMD by 3-4 spaces --for better readability
then run the following to build the image
docker build -t turris .

this will build the latest wireguard packages from the openwrt repo

once the image is built, run:
docker run --rm -v /tmp:/tmp turris

**the wireguard package will now be transferred from the docker container to /tmp/ipk on your host system


**I’m not sure the wireguard ipk is for --I didn’t install it
transfer the kmod-wireguard and wireguard-tools ipk’s to the turris omnia.

**unload the current wireguard module (if it’s loaded)
rmmod wireguard

**use opkg to remove current packages & install new packages.

**to remove the turris docker image
docker rmi turris

The turris wireguard packages are like 9 months old. There doesn’t seem to be a lot progress with anything. I had built this Dockerfile for myself, since these old packages aren’t compatible with newer wireguard versions. I’m happy to be able to share it with someone --let me know if you have any issues building it. Also…you need to be running the latest kernel which is 4.4.51 at the moment

Thank you so much! I really appreciate your sharing

I wasn’t able to update with 4.4.59 as this error showed:

arm-openwrt-linux-muslgnueabi-ld: cannot open linker script file ./arch/arm/kernel/module.lds: No such file or directory

Any Idea to update the packages in the recent version?

FROM fedora:25

ENV SDK OpenWrt-SDK-mvebu_gcc-4.8-linaro_musl-1.1.15_eabi.Linux-x86_64

RUN dnf upgrade -y &&
dnf install -y git wget bzip2 findutils ccache gcc which &&
wget --no-check-certificate https://api.turris.cz/openwrt-repo/omnia/$SDK.tar.bz2 -P /tmp &&
mkdir -p /turris/ipk &&
tar xvjf /tmp/$SDK.tar.bz2 --directory=/turris &&
rm -rf /tmp/$SDK.tar.bz2 &&
git clone https://github.com/openwrt/packages.git /turris/openwrt-packages/ &&
cp -r /turris/openwrt-packages/net/wireguard/ /turris/$SDK/package/ &&
arm_openwrt_compiler=$(find /turris/$SDK | grep bin/arm-openwrt-linux-g++) &&
arm_openwrt_ld=$(find /turris/$SDK | grep ‘bin/arm-openwrt-linux-ld$’) &&
kernel_dir=$(find /turris/$SDK/build_dir -type d | grep arch/arm/kernel) &&
echo -e “SECTIONS {\n\t.core.plt : { BYTE(0) }\n\t.init.plt : { BYTE(0) }\n}” > $kernel_dir/module.lds &&
make CXX=$arm_openwrt_compiler LD=$arm_openwrt_ld V=s -C /turris/$SDK &&
cp /turris/$SDK/bin/mvebu-musl/packages/base/*.ipk /turris/ipk/

CMD [“cp”,"-r","/turris/ipk/","/tmp"]

Hmm…it should have worked. I ran into the same issue when I was building/testing the Dockerfile.
That’s what this line is meant to fix:

echo -e “SECTIONS {\n\t.core.plt : { BYTE(0) }\n\t.init.plt : { BYTE(0) }\n}” > $kernel_dir/module.lds

That line creates the module.lds file with the following contents:

.core.plt : { BYTE(0) }
.init.plt : { BYTE(0) }

I would try it again. In any case I’ve posted an updated version that should be easier to manage going forward. With this version the only thing you’d need to change in the future is the line:
ENV SDK OpenWrt-SDK-mvebu_gcc-4.8-linaro_musl-1.1.15_eabi.Linux-x86_64
It just needs to match the SDK filename at:

Try building it again with Dockerfile I’ve just posted, and let me know if you’re successful.

BTW, I just built this image two minutes ago. It produced the following files:

Thanks, that works! Appreciate your help

I just noticed, that both routers crash with a wireguard site-to-site Tunnel after a continuos filetransfer starting at around 250mbyte. There doesn’t to seem a memory leakage as far as i can tell by free. It is completely reproducible.

Any advice?

Write the wireguard mailing list with all the details, Jason is really responsive.

This is outside of my area of expertise as troubleshooting this likely involves kernel-level debugging.
Was this issue happening with older versions of wireguard? I’ve been using wireguard without issue for the last 8 months. But, I’m not using it in the same configuration you are (site-to-site, high throughput).

Wireguard’s kernel requirements are list here:

TurrisOS meets all of the kernel requirements except for CONFIG_PADATA
$ zcat /proc/config.gz | grep PADATA (shows nothing)
There are two cores, so I’m not sure why the devs haven’t included this option

I wonder what would cause it to crash. Since wireguard runs as a kernel module, the kernel log (dmesg) would contain the most useful information for troubleshooting this issue. It’s also helpful to try and isolate the the issue to wireguard as much as possible. For example, if you’re transferring files to/from a samba share, maybe try transferring files to/from the local filesystem or usb stick and see if the symptoms are the same.

Contacting the wireguard devs directly would the best approach. If you do find the cause, please let us know what it was.

after trying out wireguard on my Omnia, i could confirm it doesn’t work with newer wireguard releases (0.0.20171017-1, from debian unstable). packets seem to just get dropped. i did not, however, see a “crash” per se - just nothing actually getting through the tunnel.

after talking with the upstream, this is expected: he described 201606 as “really old” and said the latest snapshot should have a more stable protocol interoperability.

so i put food where my mouth is an actually investigated what was missing to have an up to date wireguard in Turris, in the source. it turns out the “packages” feed is severely out of date (1+ year behind). it’s unclear which version of the feed would fix the issue - it was continuously updated in the last year or so. but even if it would be updated to the latest version, that would actually remove wireguard completely from Turris, because wireguard was moved in the base LEDE system:

and added directly in the core:

so i sent the following PR to merge wireguard directly in turris:

hopefully that will clear things up…

1 Like

aaand this was merged!

whoohoo! i guess this will be in the next release too!


Yes. This is included in 3.9. You can test it right now in RC.
We’d like to release it for everyone in next week. :slight_smile:


Is there a luci wireguard package available on the Turris?

I’ve tried looking for luci-app-wireguard and luci-proto-wireguard but can’t find any luci interface for wireguard.

EDIT: Nevermind, I managed to find luci-app-wireguard and luci-proto-wireguard over on the OpenWRT download portal/mirror.

That said, I’ve got a new issue now when I’m trying to create a new Wireguard interface. When I try to save & apply my newly created interface, I get this error message:

/usr/lib/lua/luci/dispatcher.lua:460: Failed to execute arcombine dispatcher target for entry '/admin/network/network/wgtest'.
The called action terminated with an exception:
/usr/lib/lua/luci/cbi.lua:165: Datatype error, bad token "base64"
stack traceback:
	[C]: in function 'assert'
	/usr/lib/lua/luci/dispatcher.lua:460: in function 'dispatch'
	/usr/lib/lua/luci/dispatcher.lua:141: in function </usr/lib/lua/luci/dispatcher.lua:140>

Any thoughts on how to fix the base64 error?

the provided /usr/lib/lua/luci/cbi/datatypes.lua is too old - the required base64 function was added in LEDE/OpenWrt with this commit

Perfect! I updated the datatypes.lua file and rebooted (that bit was crucial as it turned out…) and I’ve managed to get Wireguard working now. Thanks.

@Pepe: I see you’ve included parts of Wireguard in the 3.9 release but are there any plans to include Wireguard’s luci components into the package list? Is there also any plan to ensure the datatypes.lua file is kept up to date with the LEDE one so that Wireguard continues to work on the Turris going forward?

It wasn’t me, but @paja backported it and included it in 3.9. Hopefully he will give you the answer, what are you looking for.

1 Like

I am looking for wg-quick script working in BuxyBox. Any suggestion?

Yes, it will be included in our luci repo ( https://gitlab.labs.nic.cz/turris/luci-cs ). To track progress I just created issue for that https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/121