NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Getting "write: address family not supported by protocol family" when using Restic over Tailscale



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 <andreas.kahari%abc.se@localhost> 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.




Home | Main Index | Thread Index | Old Index