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=202504 header.b=QLpmKMzJ; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 966935A0282 for ; Sat, 14 Jun 2025 15:23:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202504; t=1749907379; bh=pIPhBi1EA/ajJxvETaPBbrhgDuxxUS4OafM3LEKKxfY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QLpmKMzJQWIl60Cx9+0s93BW5KbV9ACjGqRHCFukOXFVDUJQihy9WdPCwLsqjueZ8 FdJ1bnUHddLX+cRLoeGrpN9fXb8oPBU2M3E4PczvUZJWM8eOvTlxg2UjLNqCf5yYdl OflUsAwrCWpsW8DK0v4KMtKy8XNjGeo1Zm3eglxNo3uE3G8IfG18n1S/NSeqEgB+C4 VPjwCTeJH/X/ohGtrVJ9ljfiDyD33gUbQItWApdtQQa0F5yd8uv1HWLqJYxlStGn6w cayDx37c6EF7pxHGo4bCEMcaFrlNqeaGBPDUxLkFn8/jyZXloifakG5u1jsc98Rzlz ciOGovjYdS23Q== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4bKH4z6KGfz4wbx; Sat, 14 Jun 2025 23:22:59 +1000 (AEST) Date: Sat, 14 Jun 2025 23:22:53 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v2 3/8] flow: add mac address of LAN local remote hosts to flow Message-ID: References: <20250612042152.695879-1-jmaloy@redhat.com> <20250612042152.695879-4-jmaloy@redhat.com> <20250612171729.6a1144f4@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FBFcQ03i1qe4GKlJ" Content-Disposition: inline In-Reply-To: <20250612171729.6a1144f4@elisabeth> Message-ID-Hash: Q3VYXVUULP6VVLEDQVP5PQCQPWTHEDCX X-Message-ID-Hash: Q3VYXVUULP6VVLEDQVP5PQCQPWTHEDCX 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: Jon Maloy , 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: --FBFcQ03i1qe4GKlJ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 12, 2025 at 05:17:29PM +0200, Stefano Brivio wrote: > On Thu, 12 Jun 2025 00:21:47 -0400 > Jon Maloy wrote: >=20 > > 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 flowside structure is a convenient > > location for storing that address, so we do that in this commit. > >=20 > > Note that we don=B4t add usage of this address in this commit, - that > > will come in later commits. > >=20 > > Signed-off-by: Jon Maloy > > --- > > flow.c | 13 ++++++++++++- > > flow.h | 2 ++ > > 2 files changed, 14 insertions(+), 1 deletion(-) > >=20 > > diff --git a/flow.c b/flow.c > > index da5c813..fffc817 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,7 +439,7 @@ struct flowside *flow_target(const struct ctx *c, u= nion 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; > > =20 > > @@ -446,10 +447,16 @@ struct flowside *flow_target(const struct ctx *c,= union flow *flow, > > 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(ini->mac, c->our_tap_mac, ETH_ALEN); > > + memcpy(tgt->mac, 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 remote host on local network - insert its mac address */ > > + if (!memcmp(&tgt->eaddr, &ini->oaddr, sizeof(ini->oaddr))) > > + nl_mac_get(nl_sock, &ini->oaddr, ini->mac); > > break; > > =20 > > case PIF_SPLICE: > > @@ -458,6 +465,10 @@ struct flowside *flow_target(const struct ctx *c, = union flow *flow, > > =20 > > case PIF_HOST: > > tgtpif =3D fwd_nat_from_host(c, proto, ini, tgt); > > + > > + /* If remote host on local network - insert its mac address */ > > + if (!memcmp(&tgt->oaddr, &ini->eaddr, sizeof(ini->eaddr))) > > + nl_mac_get(nl_sock, &tgt->oaddr, tgt->mac); > > break; > > =20 > > default: > > diff --git a/flow.h b/flow.h > > index cac618a..916951b 100644 > > --- a/flow.h > > +++ b/flow.h > > @@ -143,12 +143,14 @@ extern const uint8_t flow_proto[]; > > * @oaddr: Our address (local address from passt's PoV) > > * @eport: Endpoint port > > * @oport: Our port > > + * @mac: MAC address of remote endpoint > > */ > > struct flowside { > > union inany_addr oaddr; > > union inany_addr eaddr; > > in_port_t oport; > > in_port_t eport; > > + unsigned char mac[6]; >=20 > We'll never have two MAC addresses that are not c->our_tap_mac in a So... there are several things to unpack here. 1) This series introduces cases where the statement as written above will not be true any more. Specifically it add cases where the (tap side) MACs are: - a real MAC from the host's LAN and - the guest's MAC Neither of these is our_tap_mac. 1a) I'm guessing you meant c->guest_mac, rather than c->our_tap_mac above. In that case it's true for the time being. It would cease to be true if we started supporting multiple bridged guests behind a single passt/pasta instance (in fact c->guest_mac would have to cease to exist to allow that). 2) If this were to go into flowside, it should be "omac" instead of just "mac". It's specifically "our" MAC in the sense that it's for frames going to/from from passt itself, rather than to/from the guest (a.k.a. the endpoint). 3) I don't think putting this in flowside makes sense for a different reason: putting it in flowside implies we need to track it for both the host side and the tap side. There are not 2, but *4* MAC addresses involved in a flow - just as there are 4 IP addresses. The two MACs on the host side, and the two MACs on the tap side. I don't think the host side omac will ever be useful. We can't control it, and it can change without warning due to reconfiguration on the host. Even without reconfiguration, multiple host interfaces could mean the host side omac is non-constant, and non-trivial to determine for a specific packet/flow. In fact if there's multipath routing, it might not even be constant for a single flow. Host side emac is what we're determining by looking at the host ARP table. But all we're doing with it is using it to initialise the tap-side omac, so I don't think we need to track it separately. It could also change during the life of a flow. If the host interface is point to point (e.g. wireguard) there will be no host side MACs at all. If the host interface is something other than ethernet there might be MACs, but they could have a different format. Tap-side omac is the key new concept in this series: we're allowing it to be set per-flow, rather than being a global constant (our_tap_mac). Tap-side emac remains a global constant (guest_mac) even with this series. As above, we'd need to change that to handle multiple bridged guests on a single passt instance. So, to accomplish what we need for this series, we only really need to track tap-side omac. I agree with Stefano that it makes more sense in flow_common than flowside. In fact, it's even more specific than that, since it doesn't make sense for spliced flows (since they go via guest loopback the guest side traffic has no MACs at all). But we don't currently have a location for pif-specific but not protocol-specific flow information, so flow_common is the closest we have. --=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 --FBFcQ03i1qe4GKlJ Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmhNd50ACgkQzQJF27ox 2Ge2ABAAkIx6uMRj1TX7qiByQiy1ctz8L3rJ5NLsF6mOXxJ0kcf3kG6ZKc8re0Nz KPfbxWaGelLi94MFVoidkyuWcJ9rczXQXT5XcDXXVzZf/tuatUJFdPj0o1BFibvo sU2i6/mJIVo6lKpq1lRznbY1ZJnsIUK1b59LsoXqrcRjYsx2ku6tJj98sVR2GXbz SzcDIWigw59+7OxegG+Gqcai9uNrPirpo50GZkiicCmqJrw1otikOkjKGiO892C6 NMQQ1ToDaBTpHd8g4voInChXxk7hZx/tS+e5g7krjNmu0JWXrr12JomRpOcK0UkF 3iWBxOFEzHAmn7Et5udER1cqFG5oe1xRIyvgBFwAaQNdXMbJSn1aQJ7W9UbD93QM vgHJNQTt+mvXa4tUsEGEc7TCcs90MxfWk7qQg3kz0mw1UIVF+Iaz4TXh5jGwAQvD 9UvEO02woLTwplrivHnzyJ8CRvQmdSGfDjGfIVoehcITRA/tL8aPRexD8AzDSco5 v0hOHCq/9HkRGeEYxPWam/Ip2tt4B5mFV4iC+HyNdqq3ZATyHGHZcHzcIUEceOo7 gRYM/1fI6xxOofEQFnbYYHdjXKUJoPjCCwku01F+xIG9ah9AJpiaw9fcmLubJN/z kKlKMfBYAIPQYzpfzWq47Ta1rels6vqt0MV3pMYZzKSHzd0zuIg= =ATkE -----END PGP SIGNATURE----- --FBFcQ03i1qe4GKlJ--