On Tue, Jun 09, 2026 at 11:42:28AM +0200, Stefano Brivio wrote:
On Tue, 9 Jun 2026 11:05:18 +1000 David Gibson
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
Reported-by: Romain Geissler 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 Reviewed-by: David Gibson
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