Skimming this thread it and sounds a lot like an issue that I ran into a
while ago with rsync backups over an OpenVPN tunnel (using tun(4)),
which would also fail mysteriously with EAFNOSUPPORT.
I tracked it down at the time to the packet-queuing logic in
tun_output() (if_tun.c:590) and have been carrying forward a local patch
that simply deletes the line that sets `error = EAFNOSUPPORT` (at
if_tun.c:632 in netbsd-11 and current).
According to the notes that I wrote up then, that assignment ended up
overwriting the actual error that was happening (ENOBUFS, set by the
IFQ_ENQUEUE macro, which doesn't occur even for AF_INET and AF_INET6
until after falling through to the AF_UNSPEC case). That is, the actual
problem was that the output buffer was filling up (which rsync etc.
should handle), but because the AF_UNSPEC path (again, which the
AF_INET(6) paths fall through to as well) unconditionally sets
EAFNOSUPPORT that ends up getting given to userspace in errno instead,
confusing rsync (and anyone reading the logs).
Indeed patching that line out solved my rsync issue, but I wasn't
confident that there weren't other potential paths I didn't understand:
as I recall from looking into the CVS history it's been that way for a
very long time (20+ years), so it seemed odd for it never to have bitten
anyone else before.
On 2026-10-18 12:52, Greg Troxel wrote:
Matti Andreas Kähäri <[email protected]> writes:
Just a tiny data point: Setting the MTU to osmething slightly lower than
1280, for example 1200, on the tun0 interface in NetBSD seems to avoid
the issue. I don't really see this as a "solution". It's a work-around.
That's hugely helpful in figuring things out.
Basically, fragmentation is bad and setups should avoid it. Packets
send on tun0 will be encapsulated with wireguard headers, and then they
will traverse the network, which could have further tunneling. In
theory whenever a packet is processed and the output doesn't fit then
the input should get an ICMP fragmentation required message (speaking
very loosely; read the RFCS!) and then send smaller packets. But often
this does not work, buggy code, firewalls that block ICMP.
You'll need to trace the packets and follow sizes across the entire
path, and that may let you understand where the problem is.
