wireguard stopped connecting, again! [solved]

[jesnow]

Wireguard just stopped connecting for no obvious reason. It was working fine yesterday, and today it doesn't. I have two issues with this.

First issue: Wireguard isn't working.

Wireguard stopped working. I can't do anything from the wireguard interface. I have to enable debugging messages using:

[pingtoo]

jesnow,

There are two part of this, User expectation and Technical error.

User expectation,

From your post it seems you expect wireguard will always work and when it is not working wireguard will notify and propagate error to entire system. So network error is reactive and Gentoo have no default setup for handle network error.

I am no expert in setting up wireguard, so I am refer to general network setup. In a general network (wired or wireless) because the connectivity function were designed layer by layer, the bottom layer is physical (as in wire, power, etc...) once bottom layer is power up and wire connect to each end, it is up to upper layer define if they can talk to each other, and each layer define different kind of condition for error correction and recovery, as some lower layer were handled in kernel and some upper layer were handled in user space.

Layers in kernel can only provide notification in term of event and capture the event is something like syslog or some program using kernel API to capture and react.

So if a connection is critical, you will need to setup tool(s) to pull or probe lower layer in kernel to see if kernel have generate event(s) indicate its current condition

I suspect wireguard have some control parameters that can set for number of connection retries and fail the connection when retry exceeding the control setting.

In term for the NFS file share failure, the NFS is a upper layer protocol, it depend on lower network connectivity to function, so in this case it is victim of wireguard not indicate connection lost therefor it is waiting for wireguard its own recovery before it will decide if any error occurred.

Technical error,

Because network connectivity depend on many predictable and non-predictable thingy, so it is very hard to say where something gone wrong,

But from your debugging session error messages it seems indicate the wireguard lost connection session and is trying to reestablish connection but failed, the message

[jesnow]

Thanks!

I do know that all the other parts of the system (DNS, etc) are working correctly and that the remote host is available.

The host merckx is in my /etc/hosts, and while it is behind a firewall and can't ping, it can ssh:

[jesnow]

I have solved this problem.

If you have rebuilt the kernel, you must re-emerge net-vpn/wireguard-tools. This installs the encryption keys for the new kernel's modules to use. You must then reboot. I was not able to get it to work using rmmod and restarting the init script. I won't get caught by this again!

Could we please add this to the gentoo wiki regarding wireguard?

I seem to recall there is an automatic list that will prompt to update packages that depend on a specific kernel build (like nvidia-drivers) does.

Cheers,
Jon.

[Hu]

The set @module-rebuild should refer to installed ebuilds that installed kernel modules. From looking at the ebuild for net-vpn/wireguard-tools, it does not look to me like it builds any kernel modules. On a system where you had this problem, what is the output of zgrep WIREGUARD /proc/config.gz ; emerge --pretend --verbose net-vpn/wireguard-tools net-vpn/wireguard-modules ; equery f net-vpn/wireguard-tools net-vpn/wireguard-modules?

[jesnow]

I think you're right: I think the modules are in the kernel and they are looking for key signatures of some kind, wireguard-tools does this at install time and at key generation time. I don't know the details, but that's why both methods work.

Now that I know what to look for I'm finding out a lot more.

Exactly emerge @rebuild-modules *should* work too, but I thought I did that.