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 Fri, Oct 30, 2026 at 08:07:00AM -0400, Greg Troxel wrote:
> Matti Andreas Kähäri <andreas.kahari%abc.se@localhost> writes:
> 
> > I have two "sibling" VM's on the same host ("henry", Alpine Linux), one
> > is "eeyore" (OpenBSD) and another is "mzulft" (NetBSD). "Sibling" means
> > I can test over the same network distance as they are next to each
> > other.
> >
> > On NetBSD:
> > mzulft% iperf3 -c henry -t 5
> > [ ID] Interval           Transfer     Bitrate       
> > [  7]   0.00-5.02   sec  60.8 MBytes   101 Mbits/sec
> > [  7]   0.00-5.03   sec  60.8 MBytes   101 Mbits/sec
> 
> > On OpenBSD:
> > eeyore% iperf3 -c henry -t 5
> > [ ID] Interval           Transfer     Bitrate         Retr
> > [  4]   0.00-5.02   sec   349 MBytes   583 Mbits/sec    0
> > [  4]   0.00-5.02   sec   349 MBytes   583 Mbits/sec
> 
> That is different and there are many possible reasons. I don't see that
> this implicates tailscale, or anything in particular.  At least it's
> well into usable rather than too painful to put up with.
> 
> > The difference is not that big, but NetBSD still clocks in at 100+ Mbit/s
> > slower than macOS.
> 
> But you do not have bare metal NetBSD on a comparable-cpu machine with a
> decent network card.

Urrg, no, sorry.

> > All NetBSD systems tested has the fix to if_tun.c applied (thanks for
> > that!).  But, as I said, I'm not personally greatly troubled by this
> > slight slowness.  I'm just happy things work.
> 
> Understood about it not being a big deal.
> 
> In the above tests, I don't see how tailscale/tun is used, as you are on
> a vm guest to vm, or on the same lan.  But it's ok that I don't
> understand.

I'm _assuming_ it's using the VPN since it's routing these 100-something
addresses over tun0.  I have more beard than sense though, at least
when it comes to networking, so I'll leave this to someone that have
greater sense of urgancy to do something about it.  Thanks!

> 
> To investigate, two approaches, neither easy:
>   - use tcpdump to record a single test tcp transfer, and then visualize
>     the details to see if there is any pathological
>   - understand the interface types, and research issues with virtual and
>     physical interfaces



Andreas