From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202602 header.b=XOx6r/e1; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 49E775A0262 for ; Thu, 28 May 2026 04:15:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202602; t=1779934539; bh=1yn2CqIDeRF+ng63vvLwhqP5pcFjLq+Gr7tDadUhvp4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XOx6r/e1S3m0OBdclhLc6EYDWxgk7XZ/eCuCLIGHfemqcQkT6pGLTs47FZPe/PAYg YHZkjc1xkVRtfq6FpBS6kN92bO2CAyc7h+KIeq+BJ5IOHRJQFEg4OTNAFjcLZQIqlm CV0CCY28ZSmNFa7wHyDAZrSLcafbP3HAhxsdxnCxMvpS4uQtxSHUyTKHp9bbRbmJJg Dh8MCfYSoTEK6bGWsbEmwPjdnA5PTQ6jtdneD3hnZi3CJfSPVKR8yG+XkqVaoiQD1u zRebq8DmbyQ50j2YX2A7YUwdEMXCiHrwCKcX/4JQ/AW/zWw7MustswZ5Zxzjp6UzKp F6xQ5WcFHE57g== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4gQqpM1pXtz4wLC; Thu, 28 May 2026 12:15:39 +1000 (AEST) Date: Thu, 28 May 2026 11:49:03 +1000 From: David Gibson To: Niklas Beierl Subject: Re: Passt port forwards to guest when host is "offline" Message-ID: References: <9262ddc4-8686-48b5-a89e-109753825999@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bsZlBLZIvK9jvv/m" Content-Disposition: inline In-Reply-To: <9262ddc4-8686-48b5-a89e-109753825999@posteo.net> Message-ID-Hash: GIQOVQKYJC3UUPO45CMV555NGYJ4DDU2 X-Message-ID-Hash: GIQOVQKYJC3UUPO45CMV555NGYJ4DDU2 X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-user@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: "For passt users: support, questions and answers" Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --bsZlBLZIvK9jvv/m Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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, > > > > >=20 > > > > > 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. > > > > >=20 > > > > > 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-c= ase > > > > > 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 I= P 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. > > > >=20 > > > > > 35.2917: ERROR:=A0 =A0Flow 0 (INI): No rules to forward HOST TCP > > > > > [127.0.0.1]:42336 -> [127.0.0.1]:3389 > > > > >=20 > > > > > This unfortunately happens quite frequently because I travel a lo= t. > > > > > I know > > > > > this scenario doesn't really have an obvious, well defined soluti= on, > > > > > 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: > > > > >=20 > > > > > Assigning an additional, static IP to the guest and somehow forci= ng > > > > > 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? > > > > >=20 > > > > > 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. > > > > >=20 > > > > > For reference: The interface definition: > > > > >=20 > > > > > =A0 =A0 > > > > > =A0 =A0 =A0 > > > > > =A0 =A0 =A0 > > > > > =A0 =A0 =A0 =A0 > > > > > =A0 =A0 =A0 > > > > > =A0 =A0 =A0 > > > > > =A0 =A0 =A0 > > > > > =A0 =A0 =A0
> > > > function=3D'0x0'/> > > > > > =A0 =A0 > > > > 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. > > > >=20 > > > > 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 gu= est > > > > 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)=A0 would > > > be the sanest choice. > > I came to the same conclusion... > >=20 > > > =A0Passt already seems to use that as a fallback for > > > --address but that never triggers on my machine, > > .. which is why this is the case... > >=20 > > > probably because when > > > "offline" I still do have ip-addresses from docker bridges but no def= ault > > > gateway? > > .. ah. Right. That could explain why "local mode" isn't triggering > > for you. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > > > Jon Maloy is currently working on a series of patches that reworks = the > > > > management of guest addresses. The primary aim is to support multip= le > > > > 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. > >=20 > > > > In the meantime there's are some workarounds you could try: > > > >=20 > > > > * 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. > > > >=20 > > > > * 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. > >=20 > > > 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. > >=20 > > > For the record, here is my workaround for the moment: I am adding a d= ummy > > > (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 netw= ork > > > with the chosen CIDR. > > >=20 > > > 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 > > >=20 > > > 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: > > >=20 > > > nmcli connection add \ > > > =A0 type dummy \ > > > =A0 ifname dummy0 \ > > > =A0 con-name dummy0 \ > > > =A0 ipv4.method manual \ > > > =A0 ipv4.addresses 192.168.250.5/24 \ > > > =A0 ipv4.gateway 192.168.250.1 \ > > > =A0 ipv4.route-metric 4294967295 \ > > > =A0 ipv6.method disabled \ > > > =A0 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. >=20 > 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 occupi= ed > 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. --=20 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 --bsZlBLZIvK9jvv/m Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmoXnwcACgkQzQJF27ox 2GcAKw//XuUKoIeL5cas0G9xNooH10QtmPxSPVvLscEf0RGD05atnOqDua4lvkBp ZuZvBnSfitrxeIeyelSLztMAPBIvuyFLPE8hPe4Tdfpd5HcSHP7BtKPQaxlvcTm5 65DIlLf10JSRhKrhKWtawGQKnGMPGaW38NWgIg/bQlJZlJX2SO4fC4m/z+8TJ2UY cmkrUH4F84YvHh7cyCg5fXYrezxw/XCp4i9+nKWtZ1HwnmpbIL+sTKBY1gPLBc8k vOtLyKcWW0V3HIetxwa2Ok3bHunddskEGnyFQvRK66qJu9TkSlvs0SdxP0S7TQP2 2GXqhm/gnsNtQjlx6WGaMH6De8f90eBHLfk49C69Z9EItRl/fzXNv1pDomk+zJo+ beDFQi7Uq1kQQTL4HrAdUSuQMh6Mc7pPOC3hPGCZRDTWK1J6R6TjX/mR3nrbBV3t KX/ShOwi3oZh5MK/3+LUKedZUN5HdsucDAYIbtggOtIhFprGRaTsaV614qC9H4tI 50vBsoF0nh13gn/MCJEKovOYfUS75ALC6QJJf0LMpssrUgGvtS3lvCKr943Cilkd /OPdehTUGMiegCEztRpPFsaG+yL4adZQ6s/hrlmhCOwCVuALlzXBTq0Lue7K0BEm 6VddkW60BVu6bTeK7su0gT0owKfKO8yUVAw5CR/twrTl4+7iBag= =lASg -----END PGP SIGNATURE----- --bsZlBLZIvK9jvv/m--