Hello! After upgrading to the latest available version 0.0.20210212 it stops starting: $ service wireguard start [#] ipfw add xxx allow ip from any to any via wg0 xxx allow ip from any to any via wg0 [#] ipfw add xxx allow ip from any to 10.10.10.0/24 xxx allow ip from any to 10.10.10.0/24 [#] ipfw add xxx allow ip from 10.10.10.0/24 to any xxx allow ip from 10.10.10.0/24 to any [#] wireguard-go wg0 [#] wg setconf wg0 /tmp/tmp.mcbM4d8l/sh-np.XJIvts and then it waits forever, terminated by ^C Had to # portdowngrade net/wireguard-go r555663 and everything runs as expected. Tried recompile (by portmaster) on both tunnel-endpoints (12.2-RELEASE-p3 GENERIC amd64 & 12.2-RELEASE-p3 GENERIC i386) with no luck. No additional diagnostic lines in /var/log/messages or the like.
Same here. For me, it hangs after the second line: [#] wireguard-go wg0 [#] wg setconf wg0 /dev/fd/63
(In reply to Rainer Hurling from comment #1) that's quite correct and the same for me - I have a firewall setup for the tunel up/down cases in config, and the upper lines are just it.
If you upgrade wireguard don't try to reboot remote servers because SSH will not come back online.
(In reply to Christos Chatzaras from comment #3) in my case there was a lad who had pressed ^ะก on the console and the boot process went on
(In reply to Oleg Strizhak from comment #4) I had to boot server with mfsbsd, mount /etc, edit rc.conf to disable wireguard and then reboot.
(In reply to Christos Chatzaras from comment #5) that's why I typed my comment #4 - ^C can be more quick and effortless solution if you have access to the console while booting
(In reply to Oleg Strizhak from comment #6) This server is in a datacenter without KVM access.
A commit references this bug: Author: decke Date: Mon Feb 15 20:35:14 UTC 2021 New revision: 565337 URL: https://svnweb.freebsd.org/changeset/ports/565337 Log: net/wireguard-go: Downgrade to 0.0.20201118 because it seems to hang for some people PR: 253537 Changes: head/net/wireguard-go/Makefile head/net/wireguard-go/distinfo
Sorry for the troubles this has caused. I've downgraded the port until the problem is resolved. A quick check of the commits since the last version did not reveal any good candidates so we need to narrow this down another way.
I've bisected it down to the upstream commit 18e4779 "device: allow pipelining UAPI requests". https://git.zx2c4.com/wireguard-go/commit/?id=18e47795e598973195887893e7d77baddec53ebb
According to Jason A. Donenfeld: "wireguard-tools tried to read trailing newlines doing scanf("%d\n\n"), which doesnt work, but it thought it did because the file descriptor was being closed by the other side unnecessarily" This resulted in the hang and both wireguard-go and wireguard-tools need to be updated then they understand each other again.
A commit references this bug: Author: decke Date: Thu Feb 25 20:41:23 UTC 2021 New revision: 566557 URL: https://svnweb.freebsd.org/changeset/ports/566557 Log: net/wireguard: Update to 1.0.20210223 and introduce options Due to a bug which was fixed in this release both net/wireguard and net/wireguard-go need to be updated or wg-quick will hang at the next start. PR: 253537 Changes: head/net/wireguard/Makefile head/net/wireguard/distinfo head/net/wireguard/pkg-plist
A commit references this bug: Author: decke Date: Thu Feb 25 20:42:41 UTC 2021 New revision: 566559 URL: https://svnweb.freebsd.org/changeset/ports/566559 Log: net/wireguard-go: Update to 0.0.20210212 Due to a bug which was fixed in this release both net/wireguard and net/wireguard-go need to be updated or wg-quick will hang at the next start. PR: 253537 Changes: head/net/wireguard-go/Makefile head/net/wireguard-go/distinfo
Now I can confirm: it works just as expected Thank you!