Filtes "Destination address required" spam on wireguard links?
Hey, I spotted one of my bird installations being quite spammy with:
babel1: Socket error on <iface>: Destination address required
Digging through the archives, I found this has previously already been reported in BFD contexts, in every occasion, wireguard being mentioned too: - 902d7906-00d5-44d0-af5a-f05a35d59195@mailbox.org - 87sevc6518.fsf@ungleich.ch - 877ccr6zio.fsf@ungleich.ch Now with me seeing this for babel, I took a closer look. It seems to be a generic behaviour with how wireguard links behave: If the peer the packet should be sent to is offline (or has not yet completed the handshake), the kernel sends a 'Destination address required' error: ``` root@flint2:~# ping fe80::5%wg_rock PING fe80::5%wg_rock (fe80::5%13): 56 data bytes ping: sendto: Destination address required ``` ``` root@flint2:~# wg show wg_rock interface: wg_rock public key: YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY= private key: (hidden) listening port: 8447 peer: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX= preshared key: (hidden) allowed ips: 0.0.0.0/0, ::/0 ``` This probably should get filtered out by babel if the interface is of wireguard type? Or in the babel case, such a message be considered as another signal that the link is down, similar to `check link yes;`? Thanks, Florian
Florian Klink <flokli@flokli.de> writes:
Hey,
I spotted one of my bird installations being quite spammy with:
babel1: Socket error on <iface>: Destination address required
Digging through the archives, I found this has previously already been reported in BFD contexts, in every occasion, wireguard being mentioned too:
- 902d7906-00d5-44d0-af5a-f05a35d59195@mailbox.org - 87sevc6518.fsf@ungleich.ch - 877ccr6zio.fsf@ungleich.ch
Now with me seeing this for babel, I took a closer look.
It seems to be a generic behaviour with how wireguard links behave:
If the peer the packet should be sent to is offline (or has not yet completed the handshake), the kernel sends a 'Destination address required' error:
``` root@flint2:~# ping fe80::5%wg_rock PING fe80::5%wg_rock (fe80::5%13): 56 data bytes ping: sendto: Destination address required ```
``` root@flint2:~# wg show wg_rock interface: wg_rock public key: YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY= private key: (hidden) listening port: 8447
peer: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX= preshared key: (hidden) allowed ips: 0.0.0.0/0, ::/0 ```
This probably should get filtered out by babel if the interface is of wireguard type?
Hmm, yeah, I think we could just ignore that particular error message in all cases. The only way it appears on a regular UDP socket is if the application sends a message without a destination address, which we should never do.
Or in the babel case, such a message be considered as another signal that the link is down, similar to `check link yes;`?
The problem with this is that there's no signal that the link comes back up, so it's probably better to just ignore the error and keep going... So probably just something like: diff --git i/proto/babel/packets.c w/proto/babel/packets.c index f18956558190..a5c7d1178716 100644 --- i/proto/babel/packets.c +++ w/proto/babel/packets.c @@ -1701,8 +1701,15 @@ babel_err_hook(sock *sk, int err) struct babel_iface *ifa = sk->data; struct babel_proto *p = ifa->proto; - log(L_ERR "%s: Socket error on %s: %M", p->p.name, ifa->iface->name, err); - /* FIXME: Drop queued TLVs here? */ + switch (err) + { + case EDESTADDRREQ: + DBG("%s: Ignoring socket error on %s: %M", p->p.name, ifa->iface->name, err); + break; + default: + log(L_ERR "%s: Socket error on %s: %M", p->p.name, ifa->iface->name, err); + break; + } } -Toke
This probably should get filtered out by babel if the interface is of wireguard type?
Hmm, yeah, I think we could just ignore that particular error message in all cases. The only way it appears on a regular UDP socket is if the application sends a message without a destination address, which we should never do.
Though it probably should be added to other protocols as well (like the observed BFD spam).
Or in the babel case, such a message be considered as another signal that the link is down, similar to `check link yes;`?
The problem with this is that there's no signal that the link comes back up, so it's probably better to just ignore the error and keep going...
True, so better to ignore this send error / degrade to debug. Florian
participants (2)
-
Florian Klink -
Toke Høiland-Jørgensen