Re: [PATCH] conf, util: Disable IPv6 if explicit IPv6 socket probe fails

[Stefano Brivio <sbrivio@redhat.com>]

On Tue, 9 Jun 2026 11:05:18 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Mon, Jun 08, 2026 at 10:24:48PM +0200, Stefano Brivio wrote:
> > In https://bugs.passt.top/show_bug.cgi?id=188, I originally reported
> > that if IPv6 is disabled in the kernel (for example via command line
> > parameter ipv6.disable=1, or disabled in build configuration), and we
> > attempt to forward any port, we'll exit right away after failing to
> > set up dual-stack listening sockets.
> > 
> > The original instance of that issue is now fixed for pasta by commit
> > 75dcbc300bf0 ("pasta: Warn, disable matching IP version if not
> > supported, in local mode") together with the new implementation of
> > the rule forwarding table, starting from commit b223bec48213 ("fwd,
> > tcp, udp: Set up listening sockets based on forward table"), because
> > we first parse forwarding options, then probe for IPv6 support in the
> > target namespace (and disable IPv6 as a result), and finally bind
> > sockets once we already know that IPv6 support is disabled.
> > 
> > But we don't do that when invoked as passt, because we have no target
> > namespace and hence no probing for IPv6 support whatsoever.
> > 
> > Add IPv6 to the socket features we test in sock_probe_features(), and,
> > if we fail to create an IPv6 socket for whatever reason (which might
> > include security policies as well), disable IPv6 support altogether,
> > so that we won't attempt to use dual-stack sockets for port forwarding
> > either.
> > 
> > Note that the probe comes without any sort of debug message, because
> > at this point we haven't parsed the configuration yet, and we would
> > therefore print that regardless of the selected logging level and
> > other options, including --ipv4-only, which would be rather confusing.
> > I doubt we'll miss this kind of message though, IPv6 support being
> > disabled is anyway obvious from the initial configuration dump.
> > 
> > Reported-by: Chi Cuong HA <ChiCuong.HA@amadeus.com>
> > Reported-by: Romain Geissler <romain.geissler@amadeus.com>
> > Link: https://bugs.passt.top/show_bug.cgi?id=188
> > Fixes: 4ddd59bc6085 ("conf: Separate local mode for each IP version, don't enable disabled IP version")
> > Signed-off-by: Stefano Brivio <sbrivio@redhat.com>  
> 
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> 
> Follow up question, though: are the tests from 75dcbc300bf0 still
> useful, or could they now be dropped as redundant?

I was wondering for a moment as well, and concluded that they're not
quite equivalent, because there might be reasons (LSMs?) why we can't
set up IPv6 connectivity in a detached namespace but we can still
create AF_INET6 sockets outside of it, so I think those checks are
still good to have for robustness.

Now, whether that presumed additional robustness justifies the added
complexity, I'm not entirely sure. I'd tend to say yes but it's by no
means a strong opinion.

-- 
Stefano