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=202510 header.b=XC0O0WON; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id B79F75A026F for ; Wed, 22 Oct 2025 04:23:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202510; t=1761099825; bh=jnjE9Nd+sUKkwCFYb1+G1S3coMMUAqfPpKhvrl+QQPc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XC0O0WONnvH4tVEsgpTGOPZB5sJlQNW0nxBsFGHFFv6XR+lOLJHYd7LUENLsj3rgH yF0c5LhLDri72tgiT7aaFhMQMDyU0ihlOwOBm5jOEeRokOPq2RnJaMbyfYi/ihdzth 3G8hx5H7Ulm3GxUxkuFWGUCOMl48kmSZhspImIDOnnHD9G51MjAeLyy8ftJK59u03m u9B0B/QBetjd6sXQJWuxzBmgrh7r+J79cclII2J7tpPXKPTjKayPWS1CcYAXsSrDes IIit0stXxBndtDbsLFqusz4uFYgIVLucre2uOhd6ZVAsONY5SD57eaelforF/qnq3N YH9vFFfaydV1w== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4crtJK6Khhz4wCk; Wed, 22 Oct 2025 13:23:45 +1100 (AEDT) Date: Wed, 22 Oct 2025 12:20:37 +1100 From: David Gibson To: Jon Maloy Subject: Re: [PATCH v14 03/10] fwd: Add cache table for ARP/NDP contents Message-ID: References: <20251015025521.1449156-1-jmaloy@redhat.com> <20251015025521.1449156-4-jmaloy@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ZjMkyicR6irX7Mzi" Content-Disposition: inline In-Reply-To: Message-ID-Hash: XBCZXFGELAGCENERTPCZONWW2JTVFQX3 X-Message-ID-Hash: XBCZXFGELAGCENERTPCZONWW2JTVFQX3 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: --ZjMkyicR6irX7Mzi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 20, 2025 at 06:00:37AM -0400, Jon Maloy wrote: >=20 >=20 > On 2025-10-19 20:06, David Gibson wrote: > > On Fri, Oct 17, 2025 at 02:49:33PM -0400, Jon Maloy wrote: > [...] > > > I also noticed it is possible to set guest_gw to some random address = while > > > at the same time setting no_map_gw. It seems to be harmless, since no= _map_gw > > > takes precedence, but it is an inconsistency we should fence > > > against. > >=20 > > No, the existing behaviour is correct. It gets confusing, because the > > guest_gw is used for magic NATs, that's often what we're referring to > > when we discuss the guest_gw address. > >=20 > > But the guest_gw is *also* exactly what it says on the tin: the > > gateway address the guest uses. Without that, the guest won't have > > connectivity at all, so we need it. --no-map-gw means we don't have > > the magic NATs, but there's still a gateway, and -g still does and > > should control its address. >=20 > So, your are telling me this is expected behaviour? As discussed on our call, yes. It's weird, but it's the most logical thing we can do under the circumstances. >=20 > jmaloy@mimir:~/passt/tests/udp_test$ /home/jmaloy/passt/passt/pasta > --config-net --no-splice -d -a 192.168.2.2 -g 192.168.2.3 --no-map-gw > Template interface: wlp1s0 (IPv4), wlp1s0 (IPv6) > Namespace interface: wlp1s0 > MAC: > host: 9a:55:9a:55:9a:55 > DHCP: > assign: 192.168.2.2 > mask: 255.255.255.0 > router: 192.168.2.3 > DNS: > 10.11.5.19 > 10.2.32.1 > DNS search list: > redhat.com > rmtcaqc.csb > NDP/DHCPv6: > assign: 2001:4958:2193:9901:6217:960c:2ef1:f0f3 > router: fe80::c23c:4ff:fe04:4638 > our link-local: fe80::c23c:4ff:fe04:4638 > DNS search list: > redhat.com > rmtcaqc.csb > Sending initial ARP request for guest MAC address > Sending initial NDP NS request for guest MAC address > SO_PEEK_OFF supported > TCP_INFO tcpi_snd_wnd field supported > TCP_INFO tcpi_bytes_acked field supported > TCP_INFO tcpi_min_rtt field supported > root@mimir:~/passt/tests/udp_test# ip r > default via 192.168.2.3 dev wlp1s0 > 192.168.2.0/24 dev wlp1s0 proto kernel scope link src 192.168.2.2 > root@mimir:~/passt/tests/udp_test# ping 192.168.2.3 > PING 192.168.2.3 (192.168.2.3) 56(84) bytes of data. > ^C^ > --- 192.168.2.3 ping statistics --- > 5 packets transmitted, 0 received, 100% packet loss, time 4080ms >=20 > root@mimir:~/passt/tests/udp_test# ping 8.8.8.8 > PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. > 64 bytes from 8.8.8.8: icmp_seq=3D1 ttl=3D255 time=3D7.68 ms > 64 bytes from 8.8.8.8: icmp_seq=3D2 ttl=3D255 time=3D20.9 ms > 64 bytes from 8.8.8.8: icmp_seq=3D3 ttl=3D255 time=3D19.1 ms > ^C > --- 8.8.8.8 ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2002ms > rtt min/avg/max/mdev =3D 7.676/15.889/20.876/5.851 ms > root@mimir:~/passt/tests/udp_test# >=20 > ///jon >=20 > >=20 > > > > In any case I think you can drop the inany_equals() test - the > > > > permanent bit will stop the second update from clobbering the first, > > > > even if we are misconfigured. > > > >=20 > > > > > + uint8_t mac[ETH_ALEN]; > > > > > + int rc; > > > > > + > > > > > + rc =3D nl_link_get_mac(nl_sock, c->ifi4, mac); > > > > > + if (rc < 0) { > > > > > + debug("Couldn't get ip4 MAC addr: %s", strerror_(-rc)); > > > > > + memcpy(mac, c->our_tap_mac, ETH_ALEN); > > > > > + } > > > >=20 > > > > Using the host's MAC for --map-guest-addr only makes sense if the > > > > guest address is the same as the host address. If -a is used to ma= ke > > > > the guest address different, then it may shadow some other random > > > > node, not the host. We don't need special handling for that case - > > > > the nat_inbound() you already have will do what we need. > > > >=20 > > > > IIUC, the host itself doesn't appear in the neighbour table, so we = do > > > > need special handling if we want to use the host MAC when > > > > --map-guest-addr *does* refer to the host. To handle that, I think > > > > what we want is pseudo-codishly: > > > >=20 > > > > fwd_neigh_table_update(c, nat_inbound(host_addr), host_mac, true= ); > > > >=20 > > > > The wrinkle is that while we do get the host address at some point, > > > > I'm not sure we keep it around (it's typically irrelevant after ini= t). > > > >=20 > > > > Strictly speaking 'permanent' isn't really correct here, but it's n= ot > > > > worth the hassle of setting up a whole other netlink monitor to wat= ch > > > > for changes in the host's MAC address. > > > >=20 > > > > In fact.. I'm not sure it's worth handling this case at all. I thi= nk > > > > it would be ok to just drop this clause. That means we'll use > > > > our_tap_mac by default for things NATted to the (non loopback) host, > > > > which is probably fine. > > > >=20 > > > Fine with me, but I do think we need a blocker entry just in case som= ebody > > > else comes up with the same address. > >=20 > > We don't need a blocker. If someone else (let's call them X) comes up > > with that address, that implies it's not the host's address. If > > that's so then --map-guest-gw will NAT to X, and that's intended. In > > which case it also makes sense to use X's MAC address. We don't need > > to do anything special to make that happen - X will appear in the host > > neigh table, and the nat_inbound() call will put it into the slot of > > the --map-guest-gw address. > >=20 > > > I'll post a complementary commit once the series has been applied. > > >=20 > > > ///jon > > >=20 > > >=20 > >=20 >=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 --ZjMkyicR6irX7Mzi Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmj4MWQACgkQzQJF27ox 2GdY8BAAqNASnWKTetL0n+caHlD5MA/VBmGwgFn6rmD80bSBU85ikvWEbMVKwJRh 2he914ZlObdeIki/oGeDJOkZ29nvf7hm5Q5HENkpMnXd6X2LHCDz8I9ccpAfHhKW 5ECdoAgvqeaVSECdKtoq3Ocoknx4T8XqX7+zUI8+5b2tED21h2TnFF3P3ZRM3kgk F8IDAHxW4ia3A9sQAuX8DK1MNG9k2IyKpPhYgU9zTJ/Aoz5/pYS6V9DvSka+HUaR NV5kqGd9KeB1wCXqT399t/0YP9o62aek7yFHuwIIR9xQ68gUFZtcfNjxETYMamY6 x4R80eOOSIgnrVNMZcBDkCwT0UYFSGp4IoTX+SstM4YUXLQ3QcT3a+r64++jS7fi TgmKxs4nBjRFQn5veb6ihc0m426YStmDRxloECtJF9S+npU5S8jv6lSPPHX7qGep lgfXakSG8iLmm+QsuAjWP14o7UlD9NXG2+Xg4LaDevQbzLnE9JD283nM34XY5QMu EfZdQXWvNqh76YKr76PQiItAMwdg/1Ijgbm12PwPvdXyLybyRweHYm1AKKuf/UFE ujUYBS0OV6VIwwVfFOr92TvtMz2FyJ40eJ0Wq0S7ANiXjv+Za1K28j3hSOK6nvhP pFWnl2k+g+nQAoSFOGAAPoqKN+Wk6kztKEHXaa04dE9ApU2r5w4= =tDtT -----END PGP SIGNATURE----- --ZjMkyicR6irX7Mzi--