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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3464 bytes --]

On Tue, Jun 09, 2026 at 11:42:28AM +0200, Stefano Brivio wrote:
> 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.

Ok, makes sense to me.

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

Right, I'm not sure either.  I guess let's leave it as is for now.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]