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=202606 header.b=RHYk1u8n; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 100EC5A0619 for ; Tue, 28 Jul 2026 07:05:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202606; t=1785215103; bh=5ijoCKoOAU+4gpBz1BCoioj1Nbj7V2G8RzbN/RFQGz0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RHYk1u8nNYiH8jorJPfouqlYNesLHIi6finhuTpsjBby1I4NfzkjALZLpSEUCDfw+ tqIFOENtd/rRMBFaJqHGy4R+vxVDBDkK3i9BHbTApnaF8CjFrmDCyeDegTcZoG2yJb 5mcg7m2CvYJTbMaGx7vr9nmhiPJRmU7rKlAKMADw+o5xYWeh8ws9AumS8KKbSVf42O /vEnB1hZ4eGfGMRvuaevZM0FpwQ02K7sE1RNxySueHMMxJKGg9llPMbd31nsTCjJJg MlfqEQH3af5jm1XCCN4ZTaGtVSJVxCXtaFwPSF8rwEMCAlZ/iKUqt/oPRd+xO7iBLl 8pVS78VwkYahQ== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4h8Ngg206bz4w1g; Tue, 28 Jul 2026 15:05:03 +1000 (AEST) Date: Tue, 28 Jul 2026 13:51:13 +1000 From: David Gibson To: Ammar Yasser Subject: Re: [PATCH] passt.1: Clearer and more detailed description of --map-guest-addr Message-ID: References: <20260721022012.44338-1-david@gibson.dropbear.id.au> <20260723012848.7c5479f6@elisabeth> <20260725144437.161d8e44@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="V2vE3DU08QwsnE0g" Content-Disposition: inline In-Reply-To: Message-ID-Hash: BDWV57QCVERRS5NF46TA7J5AVIXVMH2I X-Message-ID-Hash: BDWV57QCVERRS5NF46TA7J5AVIXVMH2I 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: Stefano Brivio , passt-dev@passt.top, Paul Holzinger , Jan =?iso-8859-1?Q?Rod=E1k?= X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --V2vE3DU08QwsnE0g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 27, 2026 at 10:46:50PM +0300, Ammar Yasser wrote: > On Mon Jul 27, 2026 at 6:30 AM EEST, David Gibson wrote: > >> and a > >> conceptual equivalent *might* be used to explain things but I think > >> it's more complicated than the alternative), and just refer to > >> addresses like the implementation does, after all. Adjusted attempt > >> below. > > > > It's difficult to explain clearly in terms of addresses only, because > > the whole trouble is the same address refers to two different things: > > on the inside it refers to the guest on the outside it refers to > > .. something, usually the host but not always. The whole "shadowed > > whatever" term is trying to get at "the thing on the outside that has > > the same address as the guest does on the inside". Ah.. sorry, I should have been clearer. I'd prefer if you can take a look at v2 of the patch, which is significantly changed. > I do agree that the notion of "shadowing" did confuse me a bit while > reading through the rewrite. If i had to use my own words to describe > whats going on with my current level of knowledge, i'd say: >=20 > passt can't allocate addresses in the host namespace. to overcome this, > an address will be picked and the guest will be made to believe that=20 > this is its own. by default, this is the host primary address. Unless=20 > another was specified through the -a option.=20 >=20 > Keeping it at that, without mentioning that -a can refer to remote > addresses is enough context for me as someone finding out about this > option for the first time to understand how to use --map-guest-addr=20 > in this paragraph Ok, noted. > >> > > > +own primary interface, because that's the address given to the = guest. > >> > > > +If the guest address is assigned with \fB-a\fR, however, the sh= adowed > >> > > > +interface will be whatever host-visible interface has the same > >> > > > +address, which could belong to any node on the host's network o= r the > >> > > > +internet. =20 > >> > >=20 > >> > > I'm not sure if -a changes this in any substantial way. I would ra= ther > >> > > leave this paragraph out, as this is already documented. =20 > >> >=20 > >> > I would say the interaction with -a is exactly what makes this > >> > confusing. That's why it has to be "map guest addr" not "map host > >> > addr" or "map template addr". > >>=20 > >> I see now. I considered it a corner case which didn't deserve much > >> attention, but, even with -a, I still think it's possible to include > >> that in the description, talking about addresses, and avoid referring = to > >> interfaces. > > > > Well, maybe, it's demonstrably difficult though... >=20 > I don't think it was entirely harmful for me to get the additional > context around interfaces. but nevertheless, as Stefano says, we can do > without it >=20 > >> > > > +The guest or namespace cannot communicate with the shadowed int= erface > >> > > > +using its host-visible address: because that's the same as the = guest's > >> > > > +address, sending packets there would loop back to the guest bef= ore > >> > > > +they're seen by passt to forward. =20 > >> > >=20 > >> > > I think this consideration should come after the description of the > >> > > option. In general we always follow a structure where we describe = the > >> > > option first, and then any consideration or motivation, so that if= the > >> > > user is not interested in the motivation, they can skip it more > >> > > conveniently. =20 > >> >=20 > >> > I agree in principle, but I'm really struggling to find a > >> > non-confusing way of describing what it does without giving this > >> > background first. Then again, from the below I'm evidently failing = to > >> > find a non-confusing way of describing even with the background firs= t. >=20 > Yes, actually giving the background, then saying that as a result to > the guest cannot communicate with this address was pretty > valuable in me understanding the problem statement Ok, useful to know. > >> > > What matters, I think, are the addresses we use, so I would try to > >> > > rephrase this to just reflect what we actually do, that is, someth= ing > >> > > on the lines of: > >> > >=20 > >> > > --- > >> > >=20 > >> > > Forward packets from the guest or container, originally directed to > >> > > \fIaddr\fR, to the host, =20 > >> >=20 > >> > It's *not* to the host if -a gives an address that doesn't belong to > >> > the host. > >>=20 > >> I'd say it still is, at Layer-2, because fwd_nat_from_tap() always > >> returns PIF_HOST (and the packets will reach the host somehow). I'm not > >> talking about routing or local delivery. > > > > The option is controlling L3 NAT, so we need to describe its behaviour > > in terms of L3 - specifically what the final L3 destination of the > > packet will be. What's happening at L2 and exactly how it's routed > > there is secondary. >=20 > Thats why i am in favor of leaving this detail entirely out of the > description of --map-guest-addr. The relevant piece of information i > need as i am specifying this option is to know why it exists (the > background + the inability to communicate with the guest assigned from=20 > the guest) and the layer 3 description of what will be the source and > destination from both sides, who will the guest and passt (by whoever is > on the other side whether its a local or remote interface) see the packets > coming from >=20 --=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 --V2vE3DU08QwsnE0g Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmpoJyMACgkQzQJF27ox 2Geqig//Sq3BRtcu26L/LburCVXfTg1AAKCiJc9qhIIn+TVCkP7x63IFZ0YVbhwt fKLXaZzif4aBIVoPTG25LQ+lg3TCP9uHahPQdk++E9ciJIyWvzZm8vxDdk8XLNBc bFfN/1hJUebFQ2Q50HQJ2HeRv8MwLscGChyZgViL0InFzRb0flG+7ixXkdxrdrYy MmjCqXCefBFiXOAiF4si890ud9Fy8Hz1NYS7uJPRfAZcpIYYFaFzXkVSSxtjIw0P nAjkJZWwTxpEShr4PWlB3QA4Muwe5dddXsuYBnQ7l6OzrpuwsO0MnOa8xaA2+VGN kvbXYLnwbAru8sZEAs1pVWxjPRuwqLTQAGCxHrxr9S38GW795fINR6Yq9daK+2Kx 5edhn+lQsQATvScFHR88ayEGpfLecsSdlxn+ju0UnSwx+eTQSD+pZK8pQOAJS6Y8 Hk8uNggsBFsuvja3n1asvUbKxeZQwD+Km+LnZ8s1lS9vuo5gSCZfcRBDYpII8NLG 88p5csLk30oSoaBB4kL+1jRfNJ0TU3O7stGJP9LgJ2UEgXStDfaCY7ZUdvXELtZF I1nOVaqXUQaevaheG1NWVXcucF8C2/OPhhl/6vtP907m5Pyz1WF/+rwPw5zO6hZW USGasW4LAlm79XNuQocF9z1OKrQHD1DAcr3XcHFo2EAHHSPh3pw= =69AL -----END PGP SIGNATURE----- --V2vE3DU08QwsnE0g--