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

[Matti Andreas Kähäri <andreas.kahari%abc.se@localhost>]

On Sun, Oct 18, 2026 at 11:18:09AM -0400, Greg Troxel wrote:
> Matti Andreas Kähäri <andreas.kahari%abc.se@localhost> writes:
> 
> > The KVM network is a bog standard IPv4-only thing that I haven't
> > changed, and which other non-NetBSD guests are using without issue.
> 
> I note that you have declined to understand and explain what it is
> doing.

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.

> 
> >> > I would suggest running "ifconfig", understanding the results especially
> >> > the address, ping and traceroute to your NAS.
> >
> > The _point_ of the Tailscale networking is to reach the NAS behind
> > my home firewall (and CG-NAT).  There is a direct route through the
> > Tailscale network, without going through any DERP server.
> 
> I understand the point.  You can't conclude from the intent that things
> are 100% ok.

Well, things are certainly not 100% ok, which is why I'm writing.

> > 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

> > 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.

> 
> > 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.

> 
> >> >   "write: address family not supported by protocol family"
> >> >
> >> > I have a very dim memory of this happening either when writing via bpf
> >> > or various tunnels, when they are configured for one address family and
> >> > the packet written isn't right (or is interpreted as not right).
> >
> > Is it maybe chopping parts of the messages off?  Unfortunately, I don't
> > really know the lower networking layers.
> 
> I would expect that a write would work or not.    But it is complicated,
> and figuring out what's wrong is very likely to need understanding.