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
On Sun, Oct 18, 2026 at 06:55:17PM +0200, Kusalananda Kähäri wrote:
> On Sun, Oct 18, 2026 at 12:13:57PM -0400, Greg Troxel wrote:
> > Matti Andreas Kähäri <andreas.kahari%abc.se@localhost> writes:
> >
> > > This is the network configuration for the guests as seen with "virsh
> > > net-edit default":
> > >
> > > <network>
> > > <name>default</name>
> > > <uuid>9aee69db-b83c-4d96-9f79-1155b3a71030</uuid>
> > > <forward mode='nat'/>
> > > <bridge name='virbr0' stp='on' delay='0'/>
> > > <mac address='52:54:00:ce:24:79'/>
> > > <ip address='192.168.122.1' netmask='255.255.255.0'>
> > > <dhcp>
> > > <range start='192.168.122.100' end='192.168.122.200'/>
> > > </dhcp>
> > > </ip>
> > > </network>
> > >
> > > What else can I tell you? I have most centainly failed (not declined)
> > > to undrestand, so please enlighten me about what further info I should
> > > supply, and how.
> >
> > Run ifconfig on the guest, and on the host. There are (at least) two
> > ways to provide networking to guests. One is to bridge the guests
> > (virtual) network interface to the (real) network interface of the host.
> > Then the guest appears to be on the same LAN segment as the host, probably
> > gets an address from the same DHCP sever, probably uses the same router,
> > etc.
> >
> > The other approach is to make the host a router, and to do
> > forwarding/nat and maybe firewall.
> >
> > I'm not familiar with KVM specifically and more importantly the
> > management practices surrounding it; I mostly use Xen. But reading
> > your xml, it says "nat" and there's an address 192.168.122.1 which is
> > probably for the hosts virtual interface that's on the same virtual
> > ethernet as the guest, and probably the guest does DHCP to a server on
> > the host and gets an address within 100-200.
>
> I believe that's how it works, yes.
>
> > Using ifconfig, or however Linux spells that, will tell you what
> > interfaces there are and what addresses are on them.
> >
> > This is probably not your problem, but I think it's always good to
> > understand your network topology.
>
> The default libvirt network is NAT: virbr0 on the host is 192.168.122.1:
>
> $ ifconfig virbr0
> virbr0 Link encap:Ethernet HWaddr 52:54:00:CE:24:79
> inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:15864743 errors:0 dropped:0 overruns:0 frame:0
> TX packets:20216576 errors:0 dropped:14 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:10945398326 (10.1 GiB) TX bytes:34680245425 (32.2 GiB)
>
> On the NetBSD guest:
>
> eeyore% ifconfig
> wm0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> capabilities=0x2bf80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
> capabilities=0x2bf80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Tx>
> capabilities=0x2bf80<UDP6CSUM_Tx>
> enabled=0
> ec_capabilities=0x7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
> ec_enabled=0x2<VLAN_HWTAGGING>
> address: 52:54:00:b3:bf:04
> media: Ethernet autoselect (1000baseT full-duplex)
> status: active
> inet6 fe80::5054:ff:feb3:bf04%wm0/64 flags 0 scopeid 0x1
> inet 192.168.122.132/24 broadcast 192.168.122.255 flags 0
> lo0: flags=0x8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33624
> status: active
> inet6 ::1/128 flags 0x20<NODAD>
> inet6 fe80::1%lo0/64 flags 0 scopeid 0x2
> inet 127.0.0.1/8 flags 0
> tun0: flags=0x51<UP,POINTOPOINT,RUNNING> mtu 1280
> status: active
> inet6 fd7a:115c:a1e0::b831:4b3d/48 -> flags 0
> inet 100.119.75.59/32 -> flags 0
>
> >
> > >> > eeyore% tailscale ping disco
> > >> > pong from disco (100.102.136.126) via XXX.255.241.178:14032 in 5ms
> > >> >
> > >> > Here, eeyore is the NetBSD system, and disco is the NAS,
> > >> > "XXX.255.241.178" is the visible IP of my home router, but since I'm
> > >> > behind a CG-NAT, I see a 100-something address on my router's actual WAN
> > >> > interface.
> > >>
> > >> But not "ping", only "tailscale ping", which implies that your routing
> > >> tables aren't set up right, and there is some tailscale wrapper that is
> > >> [speculating now] doing some LD_PRELOAD of libc to replace the
> > >> networking syscall functions with somethingelse.
> > >
> > > Sure, I can ping:
> > >
> > > eeyore% ping -c 4 disco
> > > PING disco.my-ts-domain.ts.net (100.102.136.126): 56 data bytes
> > > 64 bytes from 100.102.136.126: icmp_seq=0 ttl=64 time=6.108598 ms
> > > 64 bytes from 100.102.136.126: icmp_seq=1 ttl=64 time=6.227608 ms
> > > 64 bytes from 100.102.136.126: icmp_seq=2 ttl=64 time=5.782858 ms
> > > 64 bytes from 100.102.136.126: icmp_seq=3 ttl=64 time=5.395658 ms
> > >
> > > ----disco.my-ts-domain.ts.net PING Statistics----
> > > 4 packets transmitted, 4 packets received, 0.0% packet loss
> > > round-trip min/avg/max/stddev = 5.395658/5.878680/6.227608/0.372874 ms
> >
> > Is that going through tailscale, or not? In a normal VPN, there's a
> > route into a VPN interface for things reachable via the VPN. tailscale
> > appears to have a different plan?
> >
> > traceroute will likely shed light on this.
>
> Tailscale in-kernel tun mode is a normal VPN with a normal route.
> ("tailscale ping" is a separate thing: it probes at the Tailscale layer
> to show whether the path is direct or relayed, which is why I used it.)
>
> eyore% netstat -rn -f inet
> Routing tables
>
> Internet:
> Destination Gateway Flags Refs Use Mtu Interface
> default 192.168.122.1 UG - - - wm0
> 100.77.195.15 100.119.75.59 UHS - - - tun0
> 100.79.217.34 100.119.75.59 UHS - - - tun0
> 100.83.76.79 100.119.75.59 UHS - - - tun0
> 100.100.100.100 100.119.75.59 UHS - - - tun0
> 100.102.136.126 100.119.75.59 UHS - - - tun0
> 100.108.126.65 100.119.75.59 UHS - - - tun0
> 100.119.75.59 127.0.0.1 UGHS - - 33624 lo0
> 100.120.131.84 100.119.75.59 UHS - - - tun0
> 100.124.10.43 100.119.75.59 UHS - - - tun0
> 100.126.220.114 100.119.75.59 UHS - - - tun0
> 127/8 127.0.0.1 UGRS - - 33624 lo0
> 127.0.0.1 lo0 UHl - - 33624 lo0
> 192.168.122/24 link#1 UC - - - wm0
> 192.168.122.132 link#1 UHl - - - lo0
> 192.168.122.1 52:54:00:ce:24:79 UHL - - - wm0
>
> eeyore% route get 100.102.136.126
> route to: disco
> destination: disco
> local addr: eeyore
> interface: tun0
> flags: 0x845<UP,HOST,DONE,STATIC>
> recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
> 0 0 0 0 0 0 0 0
>
> eeyore% traceroute -I 100.102.136.126
> traceroute to 100.102.136.126 (100.102.136.126), 64 hops max, 40 byte packets
> 1 disco (100.102.136.126) 59.473 ms 5.571 ms 5.499 ms
>
> > >> > I found a similar report from April in the pkgsrc-users list:
> > >> > https://mail-index.netbsd.org/pkgsrc-users/2026/04/28/msg042883.html
> > >> >
> > >> > There, it was rsync, not restic, that triggered the error.
> > >>
> > >> Gueesing, this is probably a bug in tailscale.
> > >
> > > Possibly, or in Go on NetBSD.
> >
> > Fair point, likelihood hard to assess.
> >
> > >> > I can actually see some 500 (Internal Server Error) responses, and
> > >> > looking at the NAS logs, these corresponds to errors saying "Post
> > >> > request put error: unexpected EOF" (and the same, but with "rcat error"
> > >> > in place of "put error").
> > >> >
> > >> > It's "rclone serve restic" listening on the NAS.
> > >>
> > >> Is it run under tailscale, or does tailscale work differently there?
> > >
> > > On the NAS, Tailscale is running. The rclone service listens to all
> > > available addresses of the system, including the Tailscale addresses.
> >
> > "tailscale addresses" means what? Is there some part of RFC1918 address
> > space assigned (in your setup) to tailscale? Do they work with real
> > syscalls, and no wrappers? Why is that different on your netbsd kvm
> > guest?
>
> Tailscale hands out addresses from 100.64.0.0/10, the CG-NAT range, and
> that is the 100.x.y.z address I mean by "Tailscale addresses". Every
> node gets one on a virtual interface (tailscale0 on the Linux NAS, I
> believe), and the rclone server binds to all addresses on the machine,
> including that one. Nothing "runs under Tailscale". Tailscale
> provides a VPN (a tun interface plus routes), and programs like rclone
> just use it through normal sockets, with no wrapper involved. (There is
> a userspace-networking mode where that isn't the case, but I'm not
> using it, since plain ping and routing work as usual.)
>
> The failure shows up with large uploads, and the symptoms (unexpected
> EOF on the server, 500 errors) look like a connection being cut
> mid-transfer, so MTU/MSS is my next suspect. Tailscale's tun MTU is
> 1280, and the path from the guest through NAT adds another layer.
>
> ... but will have leave this here for now and power down my NetBSD
> experiment until next weekend.
>
> Take care,
> Andreas
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.
Andreas
Home |
Main Index |
Thread Index |
Old Index