On Wed, May 27, 2026 at 06:51:48PM +0000, Niklas Beierl wrote: > On 12/05/2026 02:49, David Gibson wrote: > > On Mon, May 11, 2026 at 12:52:45PM +0000, Niklas Beierl wrote: > > > On 11/05/2026 13:24, David Gibson wrote: > > > > On Sun, May 10, 2026 at 01:40:56PM +0000, Niklas Beierl wrote: > > > > > Hello, > > > > > > > > > > I hope I am not violating any mailinglist etiquette. I am not too > > > > > familiar > > > > > with this way of communicating and I haven't found a guide for > > > > > passts list. > > > > > Please feel free to point me out. > > > > > > > > > > I have the following Problem: I have a libvirt VM using > > > > > passt as usermode > > > > > networking backend. I set up a port-forward to access a service on > > > > > the VM. > > > > > In principle, this setup serves me well. There is just one edge-case > > > > > that is > > > > > very unergonomic: > > > > > When the VM boots while the host (laptop) is offline, the VM > > > > > get's no IP > > > > > either and the the port-forward doesn't work since passt has no IP to > > > > > forward to. > > > > Ok, this is a known problem - or, rather a known cluster of > > > > overlapping problems. There are some a fair few complications in > > > > working out exactly how best to address it though, which is why it's > > > > still there. > > > > > > > > > 35.2917: ERROR:   Flow 0 (INI): No rules to forward HOST TCP > > > > > [127.0.0.1]:42336 -> [127.0.0.1]:3389 > > > > > > > > > > This unfortunately happens quite frequently because I travel a lot. > > > > > I know > > > > > this scenario doesn't really have an obvious, well defined solution, > > > > > because > > > > > passt is supposed to just make the guest believe it has the same ip > > > > > as the > > > > > host and in this case the host has no ip. A few things I > > > > > have considered: > > > > > > > > > > Assigning an additional, static IP to the guest and somehow forcing > > > > > traffic > > > > > for it to passt. Not sure if/how this would work. > > > > > Assigning an additional, static IP on some host interface, hoping > > > > > passt will > > > > > pick it up and advertise it via DHCP? > > > > > Am I missing a more elegant approach? > > > > > > > > > > I was also thinking that it would perhaps be cool if passt could make > > > > > port-forwards for localhost connections work irrespective of > > > > > whether the > > > > > host otherwise has network connectivity. Haven't thought it > > > > > 100% through, > > > > > but if 127.0.0.1/8 is src and dst of the connection, there is no broken > > > > > return route on the guest or anything so in theory this should be > > > > > possible I > > > > > guess? I'd be happy to bounce ideas back and forth. > > > > > > > > > > For reference: The interface definition: > > > > > > > > > >     > > > > >       > > > > >       > > > > >         > > > > >       > > > > >       > > > > >       > > > > >      
> > > > function='0x0'/> > > > > >     > > > > So, this isn't really related to port forwarding at all. As long as > > > > the forward doesn't have a specific listening address (which your > > > > example doesn't), it should work fine whatever the guest address - > > > > even if the guest changes address. > > > > > > > > The problem with forwards is just due to not getting an address at > > > > all. The primary difficulty here is that if the host has no address, > > > > we have to conjure one out of thin air for the guest. But, if the > > > > host later goes online, we don't want whatever we picked for the guest > > > > to conflict with that. Finding a safe choice is quite tricky. > > > I'd venture to say that RFC3927 link-local addresses > > > (169.254.0.0/16)  would > > > be the sanest choice. > > I came to the same conclusion... > > > > >  Passt already seems to use that as a fallback for > > > --address but that never triggers on my machine, > > .. which is why this is the case... > > > > > probably because when > > > "offline" I still do have ip-addresses from docker bridges but no default > > > gateway? > > .. ah. Right. That could explain why "local mode" isn't triggering > > for you. > > > > Nevertheless link-local addresses still introduce their own > > complications. The basic question is whether the guest should be able > > to observe a "link" (in the network sense) between itself and the > > host. If it can, we can assign link-local addresses, and it simplifies > > a number of other things. However, historically the approach of > > passt/pasta has been to give the illusion to the guest that it's > > sitting in the place of the host, which implies that there not be > > guest-visible link to the host. We have real use cases that need that > > to a pretty high level of fidelity. The most obvious real-world > > consequence is whether the guest can talk to link-local neighbours of > > the host - or if the host has multiple links *which* link neighbours > > the guest can talk to. > > > > It's currently an active topic of investigation and debate whether we > > need explicit different modes (passt-link visible vs. not visible), or > > whether we can auto-select / auto-switch in some suitable way. > > > > This might seem a bit pedantic in the case of RFC3927 addresses, which > > are so rarely used. However, the analagous case for IPv6 is pretty > > routine, and we don't want to introduce inconsistencies if we don't > > have to. > > > > > > Jon Maloy is currently working on a series of patches that reworks the > > > > management of guest addresses. The primary aim is to support multiple > > > > concurrent guest addresses. However, it will also provide a better > > > > foundation on which to handle the assignment of addresses when we > > > > can't take one from the host. > > > Multiple ips would be pretty cool as you could use a link-local > > > address as > > > "fallback". :) > > Right, that's one reason why this series is a good basis or improving > > our behaviour here. > > > > > > In the meantime there's are some workarounds you could try: > > > > > > > > * What version of passt do you have? Newer versions have "local > > > > mode". It isn't perfect, but it has at least some ability to > > > > assign a guest address when the host doesn't have one. > > > > > > > > * If it's not important to you that the guest take the host address > > > > when the host *is* online, then passt has the ability to explicitly > > > > assign a guest address. You can use that via libvirt by adding > > > > lines like: > > > > > > > > > > > > to the interface block. > > > Version: passt 2026_05_07.1afd4ed. What exactly is "local mode" ? I > > > couldn't > > > identify something relevant in the man page? > > Ah, sorry, it's not an explicitly enabled feature. Instead it is > > fallback to a RFC3927 address which you observed. Older versions > > would simply fail to start if they couldn't pick an address. > > > > > I tried static IPs but it > > > seemed to me that when I use that, I also need to statically > > > configure the > > > gateway, which makes the whole thing a hassle when I do have > > > "internet" and > > > want to use it from the guest. > > Statically configuring the gateway shouldn't preclude that. We set > > the guest's gateway to match the host to maintain that illusion of the > > guest sitting in place of the host. There are some cases where it > > matters, but for most purposes it's cosmetic. You can set the gateway > > address to anything (e.g. another RFC3927 address) and the guest > > should get connectivity, even though that doesn't match the host > > configuration. passt itself is the only thing that sees where the > > guest directs the packets at the routing level, and it will make the > > given address act as a working gateway, whether or not it exists in > > the outside world. > > > > > For the record, here is my workaround for the moment: I am adding a dummy > > > (as in type dummy) interface with a private ipv4 range and a default > > > route > > > with the lowest possible precedence (high prio). This has the > > > obvious caveat > > > that I might encounter a conflict If I ever want to connect to a network > > > with the chosen CIDR. > > > > > > ip link add dummy0 type dummy > > > ip link set dummy0 up > > > ip addr add 192.168.250.5/24 dev dummy0 > > > ip route add default via 192.168.250.1 dev dummy0 metric 4294967295 > > > > > > This ensures that there always is at least a faked "local network" on my > > > machine that provides an address for the guest To persist it with > > > NetworkManager: > > > > > > nmcli connection add \ > > >   type dummy \ > > >   ifname dummy0 \ > > >   con-name dummy0 \ > > >   ipv4.method manual \ > > >   ipv4.addresses 192.168.250.5/24 \ > > >   ipv4.gateway 192.168.250.1 \ > > >   ipv4.route-metric 4294967295 \ > > >   ipv6.method disabled \ > > >   connection.autoconnect yes > > That seems like a perfectly cromulent workaround, though statically > > setting guest address and gateway to RFC3927 addresses might be a bit > > more elegant. > > I am not sure about the specifics, but it struck me today that perhaps it > would be for passt to signal a physical medium disconnect to the interface > in the guest. > Qmp seems to provide such functionality via set_link > https://qemu.eu/doc/8.0/interop/qemu-qmp-ref.html#qapidoc-1384, but QMP is > probably rather unergonomic for passt to interface with. As far as I > understand, QMP sockets only support one session that is typically occupied > by someone else (libvirt). Yeah, an out-of-band means of signalling like that won't really work. > I don't know if the socket interface for netdev has such functionality? Alas, it does not. The socket netdev protocol is *extremely* simple. It might be possible with the vhost-user backend, which we generally prefer these days. > Sounds like something that could perhaps be added tho. Theoretically, yes, but it's a non-trivial change to a trivial protocol, so I'm a bit leery of it. > To tie this to the original problem: passt could offer a mode in which it > tracks changes in host connectivity, i.e. default route becoming > (un)available, then signals a medium dis- and re-connect to the guest to > trigger DHCP. There are probably easier ways for us to retrigger DHCP. We can use explicit DHCPNAKs, or set shorter timeouts than the ones we do 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