7:15 a.m.
On Tue, Jun 24, 2025 at 01:57:09PM +0200, Stefano Brivio wrote:
On Tue, 24 Jun 2025 12:33:17 +0100
"Richard W.M. Jones" <rjones(a)redhat.com> wrote:
> I'm a bit confused here. How does host IPv4 or IPv6 affect what
> happens in the appliance?
The appliance still needs to connect to hosts using IPv4 or IPv6
addresses.
My hope was simply that availability of IPv6 would work around the
issue, because IPv4 isn't configured here (due to the issue I'm pointing
out).
OK I see, I think. By "isn't configured" you mean because we pick the
sit0 interface instead of eth0? (Obviously that's wrong, but the
"ls -I" command is a bit of a hack.) We could add "-I sit" there.
The interface appliance/init selects to configure IPv4 via DHCP is
sit0 instead of eth0.
> For example if the host only had IPv6, it should still work wouldn't
> it?
With IPv6 only, appliance/init would at least need to bring up the
interface to configure the interface via SLAAC. I don't see it being
done, so, unless it's done implicitly somewhere, that shouldn't work,
either.
I guess that should be fixed as well, with, say:
ip link set "${iface}" up
> Also I'm confused where sit0 comes from (or even what it is, really).
> Why does it appear inside the appliance at all?
See original report from Aithal for full details (and in my opinion a
reasonable request to offer a way to disable the module inside the
appliance).
"the module" meaning ipv6/sit.ko?
Long story short, you configure the kernel with CONFIG_IPV6_SIT, and
the kernel will automatically create the sit0 interface at boot, which
causes appliance/init to ask dhclient to configure it (instead of eth0).
SIT stands for "Simple Internet Transition" and it's essentially the
6to4 (https://en.wikipedia.org/wiki/6to4) implementation on Linux. It's
not supposed to be used in the appliance at all, but the interface
appears merely because the kernel is configured with it.
> My mental model is that passt provides an IPv4 address inside the host
> on eth0. If the host has, say, only IPv6, then requests would be
> proxied out over that. We don't care how that happens precisely.
Protocol families are not simply proxied between each other because
there's no shared address space between IPv4 and IPv6.
If passt is like slirp, then it would originate connections itself
(ie. calling connect(2) on the host side), so I don't understand how
the address family would be relevant. I guess passt is not like slirp
in this regard?
Let's say you connect to 88.198.0.164 from the appliance, but
there's
no IPv4 routing available on the host: passt will *not* reverse-resolve
88.198.0.164 to passt.top and connect you to 2a01:4f8:222:904::2
instead. That would be kind of surprising and add convoluted DNS
requirements.
We have a request for CLAT:
https://bugs.passt.top/show_bug.cgi?id=43
where one could do something like that, but you would need to configure
it explicitly (the day it's implemented).
In any case, this has all little to do with the actual issue. The
problem is that the appliance runs dhclient or dhcpcd on sit0 instead
of eth0, because excluding "all", "default", and "lo" is
not enough. If
you prefer a minimal fix:
iface=$(ls -I all -I default -I lo -I sit0 /proc/sys/net/ipv4/conf)
Yes, this seems like the more obvious change, but there seems there
might be something very deep that I'm missing here.
would also work.
I can send a patch, too, but it might take me a while before I find a
moment to prepare the test setup.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top