On 2024/12/17 20:17, Lloyd wrote: > I've been running the Wireguard logging patch I submitted to -tech > for a few days > with little other issue. Recently I did some testing with a device > over cellular > (dynamic client behind CG-NAT). The testing was completed and the > client powered > off and disconnected from the remote network. In other words, it was > no longer > at the remote IP address (typical of a roaming client).
There isn't a notion of "server" and "client" in the protocol, just different endpoints. > The next morning I checked the syslog to find 17 hours worth > of the following messages (until I rebooted the box), repeated > every 5 seconds, with x.x.x.x is the remote IP address of the > wireless provider's CG-NAT server: Wireguard dossn't timeout the remote side. Otherwise how would you get a connection to start up again after it was dropped? That's common for wkreguard, not specific to wg(4). > --snip-- > 09:27:00 wg0: Sending handshake initiation to peer 0 (x.x.x.x) > 09:27:05 wg0: Handshake for peer 0 (x.x.x.x) did not complete after 5 > seconds, retrying (try 2) ... > 09:28:18 wg0: Sending handshake initiation to peer 0 (x.x.x.x) > 09:28:23 wg0: Handshake for peer 0 (x.x.x.x) did not complete after 5 > seconds, retrying (try 2) > --snip-- > > As you can see, it appears the Wireguard service will continue to try > and reach out to > the remote endpoint forever, even after it's long gone. If I > understand correctly, it's > supposed to try MAX_TIMER_HANDSHAKES times (aka 18) then stop. The > log entries most often > have the value of "try 2" repeated, with occasional "try 3". I grep'd > the logs and over > 17 hours of data, I have exactly 4 log entries of "try 4" and 3 log > entries of "try 5". I think this relates to retries for one handshake attempt. If there's traffic to send to an endpoint and there's no active handshake it will attempt a new handshake. If that handshake doesn't complete then that traffic will (after a while) get dropped but new traffic will attempt another handshake. Do you have continuing packets (or keepalives) to send over wg(4) to this endpoint? If you do then it seems to me that it's working as designed. (If you want something which does expire if the other doesn't maintain a connection, IKEv2 is probably a more suitable protocol - one reason why people use wireguard is specifically because it has this type of behaviour).
