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=fP4grlBx; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id DB0A05A0619 for ; Thu, 09 Oct 2025 05:51:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202510; t=1759981885; bh=MawhTsAt8bzPKfI2YSixenENV0clwDpZkErXeCycU0I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fP4grlBx3AlAdhBw+F/Q4fBKxHGvt85yzASXk2XTroq1wc0GO/BmeW2+p3lQLACBv 2OVBIE0UaxSPEAhuW1ZdJhsRXkF2PJU1g0U8VkPj6kMkmNuP/JGjwty0MoV4lkANh7 YRxuCjyjWDCiuz0Aa6rpXLJ5HSKQHlkyLLhEXiyqxS1kGEjtEbO1KJqSKkYMzAySb9 afnwHMpvt5YOTVXqsq1LotpZL+tW5Pd19KINhAThzgIdi40oHaT8CQhzBYRRhr2ioo ppsWl1jcofEqpJjh2kwDejgR/kE9uTLFFaIOnZlmZAPa1/XZrnNU7npc07sA/K74mi qhNisKCiux8qg== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4chwsT695hz4wCQ; Thu, 9 Oct 2025 14:51:25 +1100 (AEDT) Date: Thu, 9 Oct 2025 14:51:02 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v12 3/9] arp/ndp: send ARP announcement / unsolicited NA when neigbour entry added Message-ID: References: <20251003003412.588801-1-jmaloy@redhat.com> <20251003003412.588801-4-jmaloy@redhat.com> <20251007121022.353a44fc@elisabeth> <20251008120118.046339db@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="G8HogO7ERefGf24N" Content-Disposition: inline In-Reply-To: <20251008120118.046339db@elisabeth> Message-ID-Hash: MWRRGFLIH7AE32KNIFBK66DC7TYFSVLA X-Message-ID-Hash: MWRRGFLIH7AE32KNIFBK66DC7TYFSVLA 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: --G8HogO7ERefGf24N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 08, 2025 at 12:01:18PM +0200, Stefano Brivio wrote: > On Wed, 8 Oct 2025 11:27:32 +1100 > David Gibson wrote: >=20 > > On Tue, Oct 07, 2025 at 12:10:22PM +0200, Stefano Brivio wrote: > > > On Fri, 3 Oct 2025 14:41:56 +1000 > > > David Gibson wrote: > > > =20 > > > > On Thu, Oct 02, 2025 at 08:34:06PM -0400, Jon Maloy wrote: =20 > > > > > ARP announcements and unsolicited NAs should be handled with caut= ion > > > > > because of the risk of malignant users emitting them to disturb > > > > > network communication. > > > > >=20 > > > > > There is however one case we where we know it is legitimate > > > > > and safe for us to send out such messages: The one time we switch > > > > > from using ctx->own_tap_mac to a MAC address received via the > > > > > recently added neigbour subscription function. Later changes to > > > > > the MAC address of a host in an existing entry cannot be fully > > > > > trusted, so we abstain from doing it in such cases. > > > > >=20 > > > > > When sending this type of messages, we notice that the guest acce= pts > > > > > the update, but shortly later asks for a confirmation in the form= of > > > > > a regular ARP/NS request. This is responded to with the new value, > > > > > and we have exactly the effect we wanted. > > > > >=20 > > > > > This commit adds this functionality. > > > > >=20 > > > > > Signed-off-by: Jon Maloy > > > > >=20 > > > > > --- > > > > > v10: -Made small changes based of feedback from David G. > > > > > v11: -Moved from 'Gratuitous ARP reply' model to 'ARP Announcemen= t' > > > > > model. > > > > > v12: -Excluding loopback and default GW addresses from the ARP/NA > > > > > announcement to be sent to the guest > > > > > --- > > > > > arp.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > > > > > arp.h | 2 ++ > > > > > fwd.c | 16 ++++++++++++++++ > > > > > ndp.c | 10 ++++++++++ > > > > > ndp.h | 1 + > > > > > 5 files changed, 71 insertions(+) > > > > >=20 > > > > > diff --git a/arp.c b/arp.c > > > > > index ad088b1..b08780f 100644 > > > > > --- a/arp.c > > > > > +++ b/arp.c > > > > > @@ -146,3 +146,45 @@ void arp_send_init_req(const struct ctx *c) > > > > > debug("Sending initial ARP request for guest MAC address"); > > > > > tap_send_single(c, &req, sizeof(req)); > > > > > } > > > > > + > > > > > +/** > > > > > + * arp_announce() - Send an ARP announcement for an IPv4 host > > > > > + * @c: Execution context > > > > > + * @ip: IPv4 address we announce as owned by @mac > > > > > + * @mac: MAC address to advertise for @ip > > > > > + */ > > > > > +void arp_announce(const struct ctx *c, struct in_addr *ip, > > > > > + const unsigned char *mac) > > > > > +{ > > > > > + char ip_str[INET_ADDRSTRLEN]; > > > > > + char mac_str[ETH_ADDRSTRLEN]; > > > > > + struct { > > > > > + struct ethhdr eh; > > > > > + struct arphdr ah; > > > > > + struct arpmsg am; > > > > > + } __attribute__((__packed__)) annc; > > > > > + > > > > > + /* Ethernet header */ > > > > > + annc.eh.h_proto =3D htons(ETH_P_ARP); > > > > > + memcpy(annc.eh.h_dest, MAC_BROADCAST, sizeof(annc.eh.h_dest)); > > > > > + memcpy(annc.eh.h_source, mac, sizeof(annc.eh.h_source)); > > > > > + > > > > > + /* ARP header */ > > > > > + annc.ah.ar_op =3D htons(ARPOP_REQUEST); > > > > > + annc.ah.ar_hrd =3D htons(ARPHRD_ETHER); > > > > > + annc.ah.ar_pro =3D htons(ETH_P_IP); > > > > > + annc.ah.ar_hln =3D ETH_ALEN; > > > > > + annc.ah.ar_pln =3D 4; > > > > > + > > > > > + /* ARP message */ > > > > > + memcpy(annc.am.sha, mac, sizeof(annc.am.sha)); > > > > > + memcpy(annc.am.sip, ip, sizeof(annc.am.sip)); > > > > > + memcpy(annc.am.tha, MAC_BROADCAST, sizeof(annc.am.tha)); > > > > > + memcpy(annc.am.tip, ip, sizeof(annc.am.tip)); =20 > > > >=20 > > > > As noted in several earlier revisions, having sip =3D=3D tip (but w= ith > > > > different mac addresses) looks odd. Is that what the RFCs say to do > > > > for ARP announcements? > > > > =20 > > > > > + inet_ntop(AF_INET, ip, ip_str, sizeof(ip_str)); > > > > > + eth_ntop(mac, mac_str, sizeof(mac_str)); > > > > > + debug("Announcing ARP for %s / %s", ip_str, mac_str); > > > > > + > > > > > + tap_send_single(c, &annc, sizeof(annc)); > > > > > +} > > > > > diff --git a/arp.h b/arp.h > > > > > index d5ad0e1..4862e90 100644 > > > > > --- a/arp.h > > > > > +++ b/arp.h > > > > > @@ -22,5 +22,7 @@ struct arpmsg { > > > > > =20 > > > > > int arp(const struct ctx *c, struct iov_tail *data); > > > > > void arp_send_init_req(const struct ctx *c); > > > > > +void arp_announce(const struct ctx *c, struct in_addr *ip, > > > > > + const unsigned char *mac); > > > > > =20 > > > > > #endif /* ARP_H */ > > > > > diff --git a/fwd.c b/fwd.c > > > > > index c34bb1c..ade97c8 100644 > > > > > --- a/fwd.c > > > > > +++ b/fwd.c > > > > > @@ -26,6 +26,8 @@ > > > > > #include "passt.h" > > > > > #include "lineread.h" > > > > > #include "flow_table.h" > > > > > +#include "arp.h" > > > > > +#include "ndp.h" > > > > > =20 > > > > > /* Empheral port range: values from RFC 6335 */ > > > > > static in_port_t fwd_ephemeral_min =3D (1 << 15) + (1 << 14); > > > > > @@ -140,6 +142,20 @@ void fwd_neigh_table_update(const struct ctx= *c, const union inany_addr *addr, > > > > > =20 > > > > > memcpy(&e->addr, addr, sizeof(*addr)); > > > > > memcpy(e->mac, mac, ETH_ALEN); > > > > > + > > > > > + if (inany_equals(addr, &inany_loopback4)) > > > > > + return; > > > > > + if (inany_equals(addr, &inany_loopback6)) > > > > > + return; =20 > > > >=20 > > > > Since you need these explicit checks anyway, there's not much point= to > > > > the dummy entries you created - you could exit on these addresses > > > > before even looking up the table. =20 > > >=20 > > > I guess those entries make sense if we can drop all these checks as a > > > result. I think we should be able to. =20 > >=20 > > We couldn't in this version, because that might have allowed the > > entries for loopback to be updated, which is certainly wrong. But > > it will all need re-examination after moving everything over to guest > > side addresses which AIUI is the plan for the next spin. >=20 > Yes, I was talking about the next version. For context, when we first > discussed about the possibility of these entries with Jon, my > assumption was that the whole series used guest-side link-layer > addresses exclusively, We did use guest-side link-layer addresses - host-side LL addresses might not even exist. The question is about whether we use guest side or host side IP addresses to index the table. > but that wasn't the case, hence (I think) the > current struggle. If we go in that direction, I hope it's possible. Thinking a bit more closely, I don't think it is, for much the same reason it wasn't in this draft. According to the rules Jon and I thrashed out elsewhere in the thread, there are certain guest side addresses that must be locked to use our_tap_mac. We're essentially shadowing something that might exist on the host side, so we should use our MAC not the MAC of whatever is shadowed. Just pre-populating an entry won't do the trick, because it could be overwritten if the right events occur for the shadowed host. > By the way, while they are probably more elegant because we can skip > explicit cases, they might be a bit more complicated to manage compared > to those explicit cases the day we get to change addresses and routes > dynamically using a netlink monitor, because at that point we might > need to remove some entries based on old addresses / default gateways. >=20 > But given that this is already complicated enough, we can keep that > problem for later, and just go with the simplest possible approach > (whatever it is) for the moment. >=20 > --=20 > Stefano >=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 --G8HogO7ERefGf24N Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmjnMSUACgkQzQJF27ox 2Gc3pQ/+PEj1gAxDNzamhWD9XCk8VCVYAzKyHiSFjf76HibrQPNfSElqNcp6k2m7 6eKb3Of1k18hnoYd9s1C5KBW0DZGpHZ5aelMjo9B4kkY6CeSf8X42unqcLVlQL8P tMlR2b7BjgxvbQrLGeI53UAUZZIyRdFIwFcRQGfqYZUCxx4b0mIRH3ZQEYxVWYg0 HYPWmh0fREZsUgxH4yRts+P0smkD1OUbXJnEC7/jQwGJEbWdI2EzuHzgCvb/Dp9D PyCzcMArS0Ye7XWU67znl6wrvqNNZqz9Fsbw8PngZu5x6JzG9pEAJ3BLn80jGmdA lKF+meDc5UBduYcarrR1zZu/szqRQ8YQYloGGdXE8uEnmYAKlkac3AL8DmLeXcE0 5m8BqVwpfPWi651f8uyTBzpJG6b0Gd5bF5nKarj8lcKuiPi0oiZ8xvOwLJjn1/7j 8FrR3eEpPNDclfjtGFEL+rDROiADCC6thr3IFXIb9BrI6af6laPM/OkQ9V7yMTgi F6pMULWLXbypAVGFHFEs0spovhPBEcPB/sfk/706AqxpqqnzJaetJ+s98SVOSYm5 RgQt2gNEGGz12embZp94g23YgeDfi9u3S/63UbXMBe3CcLEtZYk8H+IeAzEXZpc3 zz8TmL6235PM5d6yUKrB/PuNvl1mT7DvuCq5fVWrND+bQmLmyhI= =4nlL -----END PGP SIGNATURE----- --G8HogO7ERefGf24N--