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=202506 header.b=b/zN7Wpu; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 5ECDF5A0285 for ; Tue, 22 Jul 2025 04:44:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202506; t=1753152124; bh=wu/1GlEcthEMze7Qtu4uDBlAQzLGp27XI0uDrmVcbVc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=b/zN7WpueqRXadNwnN5XHx2sx73u9OsHXmco0WXF6MTYCCDAj8LKqODsN2MlctigO 46F/XJ83Fr/Qb5ytL0T96kIc87ak0ERyWf4Xt+QeLu92uyNVzsHJ13TQbw60wVKRWW 2XHPTrLMZaqwA9e90OEekq3v1tdJD3xZcJhU8Nl5a42d1qorFACDsUFeH2UIfTM/hj SweIDCoc4fwmTweVCOjBSkq6WGOt5bGePy0j4gwi4bM3Q2pWorxiBw8YXIL5QbHbPn p4Z/VMJR40G7RdidSUG4Shg42zxBKzXGKa8NaZkWikmchXoQkAeoaQDnfTpZPI6oB7 zCLBtjNoo+gGA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4bmM3w37Xdz4x21; Tue, 22 Jul 2025 12:42:04 +1000 (AEST) Date: Tue, 22 Jul 2025 12:33:55 +1000 From: David Gibson To: Jon Maloy Subject: Re: [PATCH v3 3/8] flow: add MAC address of LAN local remote hosts to flow Message-ID: References: <20250629171348.86323-1-jmaloy@redhat.com> <20250629171348.86323-4-jmaloy@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3UTtXnk9oNqQRXEr" Content-Disposition: inline In-Reply-To: Message-ID-Hash: K2B5TKPUNZ5CUCR7C3KS6S455UZGDN7E X-Message-ID-Hash: K2B5TKPUNZ5CUCR7C3KS6S455UZGDN7E 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: sbrivio@redhat.com, dgibson@redhat.com, passt-dev@passt.top 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: --3UTtXnk9oNqQRXEr Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 22, 2025 at 12:12:25PM +1000, David Gibson wrote: > On Sun, Jun 29, 2025 at 01:13:42PM -0400, Jon Maloy wrote: > > When communicating with remote hosts on the local network, some guest > > applications want to see the real MAC address of that host instead > > of PASST/PASTA's own tap address. The flow_common structure is a > > convenient location for storing that address, so we do that in this > > commit. > >=20 > > Note that we don=B4t add actual usage of this address here, that will > > be done in later commits. > >=20 > > Signed-off-by: Jon Maloy > >=20 > > --- > > v3: - Moved the remote host macaddress from struct flowside to > > struct flow_common. I chose to call it 'omac' as suggested > > by David, although in my understanding the correct name would be > > 'emac'. (In general I find the address naming scheme confusing.) >=20 > Sorry, I probably wasn't entirely clear there. There are two related > but distinct concepts here. There's the host facing 'emac' - the real > MAC address of the host neighbour. Then there's the guest facing > 'omac', the source MAC address we use when sending on the tap > interface. >=20 > [There's also conceptually a host facing 'omac' - the host's MAC on > the host interface, and a guest facing 'emac' - the guest's MAC > address on the tap interface, but those aren't really relevant here] >=20 > The whole point of this series is to make guest-omac equal host-emac > when possible - but it's not always possible. Given that, guest-omac > is the one it makes sense to track. That's the one we actually need to > put into packets. When the peer isn't in the neighbour table the > guest-omac is well defined (our_tap_mac) whereas the host-emac is > simply unknown (and might or might not become known later). >=20 > But now that this is in flow_common, instead of flowside, we do need > to disambiguate which side we're talking about. So it should probably > be 'tap_omac'. >=20 > > - Adapted to new signature of function nl_mac_get(), now passing > > it the index of the template interface. > > --- > > flow.c | 21 ++++++++++++++++++++- > > flow.h | 2 ++ > > 2 files changed, 22 insertions(+), 1 deletion(-) > >=20 > > diff --git a/flow.c b/flow.c > > index da5c813..dcda1a7 100644 > > --- a/flow.c > > +++ b/flow.c > > @@ -20,6 +20,7 @@ > > #include "flow.h" > > #include "flow_table.h" > > #include "repair.h" > > +#include "netlink.h" > > =20 > > const char *flow_state_str[] =3D { > > [FLOW_STATE_FREE] =3D "FREE", > > @@ -438,18 +439,28 @@ struct flowside *flow_target(const struct ctx *c,= union flow *flow, > > { > > char estr[INANY_ADDRSTRLEN], fstr[INANY_ADDRSTRLEN]; > > struct flow_common *f =3D &flow->f; > > - const struct flowside *ini =3D &f->side[INISIDE]; > > + struct flowside *ini =3D &f->side[INISIDE]; > > struct flowside *tgt =3D &f->side[TGTSIDE]; > > uint8_t tgtpif =3D PIF_NONE; > > + int ifi; > > =20 > > ASSERT(flow_new_entry =3D=3D flow && f->state =3D=3D FLOW_STATE_INI); > > ASSERT(f->type =3D=3D FLOW_TYPE_NONE); > > ASSERT(f->pif[INISIDE] !=3D PIF_NONE && f->pif[TGTSIDE] =3D=3D PIF_NO= NE); > > ASSERT(flow->f.state =3D=3D FLOW_STATE_INI); > > + memcpy(f->omac, c->our_tap_mac, ETH_ALEN); > > =20 > > switch (f->pif[INISIDE]) { > > case PIF_TAP: > > tgtpif =3D fwd_nat_from_tap(c, proto, ini, tgt); > > + > > + /* If there was no NAT, chances are this is a remote host > > + * on the template interface's local network segment. > > + * If so, insert its MAC address > > + */ > > + ifi =3D inany_v4(&ini->oaddr) ? c->ifi4 : c->ifi6; > > + if (inany_equals(&ini->oaddr, &tgt->eaddr)) > > + nl_mac_get(nl_sock, &ini->oaddr, ifi, f->omac); >=20 > Again, if this is the first time we're contacting that peer, it won't > be in the ARP table yet. Following on from this, having read more of the series: In this case (unlike the guest ARP handling) the peer's MAC won't change (as it appears to the guest), because we set it in the flow then never update it. At the very least that means that this basically won't work reliably for any protocol where the guest is making first contact to the peers (and the host hasn't happened to communicate with those same neighbours). They'll all just appear as our_tap_mac to the guest on the first flow, then may appear either as that or the correct map on later flows depending on whether the host's neighbour entry timed out or not. It also has another weird consequence: we'll keep using the original MAC we picked for the flow, even if we're concurrently answering ARPs =66rom the guest with a different MAC. --=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 --3UTtXnk9oNqQRXEr Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmh++JIACgkQzQJF27ox 2Gdv+g//WXbu7g3t68lg2t6VtDiIbQKXeo7q5rfimRllfjzLLL6utG66aOxExctz 1goSLK+LswOcJzgzUCU33vpbv+K2yRSuUh/b5S54iUkPkseD8lRo76XCwcFjDlJI N0F9zmqSF0TMjfmtGSV0i7+lVb5V36UvWMPhjYPFk33fCmKlFaaoxP/3OT9uw1sL ds5Tahy5vde5uY/imnIuHBCCYmsPrbdKHur3bJgaXREgAYYMH/2IqfsoojTjtmNW 41EdnZMnJ6NbkscoI3vxkI6JDckG007n7NvSj1e9G8qAFQIOBqFCnacagAKk8KA1 B/YQ+Rv82BkwcHF3pvNjxxuMQgdkYUIVAOeaVFpf1CFPxA/Dc1g1vTG8RvWZiA0E vegE8+snTftLX3vuGNdF+Y/7veG1jFnI7uSiH7z7asFtofijGsN+6R1j2r/Iytvl S/BvGI+joFQWQbLvgVh7ZQCiJ/3F3VBeOxJBaFl3U374mzH1mPG890NwWzKZzjks 0yNfnW7T6QcrgG5UOIvkG1LCeqW39rmFoPfLx3md3U7y+Om6nTMLf2mac/zSrX4w UYePUmG8vJeRWbb/RMDGZtSF/d8JXvCYeJP4TI4usOtlyH8CZk2ZO0XvGnX0MRaB boYFIfWoe0NP49ztR571ypBXFf6KfaD+NDrHl4ScifI4cbbLZSo= =wvqc -----END PGP SIGNATURE----- --3UTtXnk9oNqQRXEr--