From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=RaHlNH3M; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 6233A5A026F for ; Tue, 07 Oct 2025 12:10:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1759831827; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9oDEKeJ0bUWpdUmpNg8u3Jg1vJwST7LEwZiq5ArejJg=; b=RaHlNH3MTvhic1vyotNr+0mZbjZAM3I/SOFhgKHjJ+BDQcanY68FuXaTxJQXTw18pUVc4M BQ9YACknwMTNxdr/k3uM3G5wXafg4Ymmx8H9iC2p6bVKTR7bmibseAkyyIpMOioKEBYcEl MpApOgtIgzSOqT6cAyMA+Pv0fx/2N6Q= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-411-xEeDErb3PtS8GsSuVj6_xw-1; Tue, 07 Oct 2025 06:10:26 -0400 X-MC-Unique: xEeDErb3PtS8GsSuVj6_xw-1 X-Mimecast-MFC-AGG-ID: xEeDErb3PtS8GsSuVj6_xw_1759831825 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-3ee1365964cso4587786f8f.2 for ; Tue, 07 Oct 2025 03:10:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759831825; x=1760436625; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=9oDEKeJ0bUWpdUmpNg8u3Jg1vJwST7LEwZiq5ArejJg=; b=MN9cqqmcF7dBzu0yfINRZ0zpM7gN7b7DgSrMHRTsKsdYvofQaMJZVgqn/ukuEwph/1 OGUKLO8PJzl2EOYg4vqlTzozpff8v2ywHaFrU236JhaAhICOh08WImQ+kpFWY0WiHO28 50bIpRiWNsm29Jo1zbTdVNwyMMnBb0zxLZZL2PNNWUJ/Rkv/J5K5cE1pbAuu+9mBauY0 BcGUBJg1sagZi9eTgdz4FPuxBmw0fBEDgFlBwulqbL9rYMTpFSRWOetYlUzphuMrg3cH raPV8sk+OGVXOY4W2imJ8xtVBtckxjodRN0yUmc2pKfsZPbVTqhY+iCAWHGFPi/HUZov X0nA== X-Forwarded-Encrypted: i=1; AJvYcCVcVuZ2d1LUDoqNJSnTpjU0H3Y2yteovGV4PZd65ue0st46VujR0RAw60JYIdCL7s3n0y+XAub76ss=@passt.top X-Gm-Message-State: AOJu0YylUFmIUc4avuaJLncH8xExlNNkbIf+xLbaA1F9/TRSvQRzy5oo +2jjHyu2LmGnuQNbTt6SSaq8dO58pmgp8k4rYCxP1EMPAvX8Nz8qNddB7SlzuKepiVMRqsWEjg3 WGtk/dYzHNPDsCxNMSOPGhKiABRg5r5sD9uJgiMTTaNDN+GsIJsyfFg== X-Gm-Gg: ASbGncuSpUe/5ipvy8w6ThM2bZYQqEXCGGI1lfUuyMOzyfmAKgOe1VkDkMS0dE5PPuk z1jzm73JOJvoaIFhcApwY/AF4in7Z27DahbrEja469/N5s2AoA5coJqqQOW/kRWYmPQfe9brH/i 8LhAxFBgql29NjAiaOhHQ7PmDB1erL60yeajyQwU4dGUKnFdjkqfvrDzdPyYjFk4X1/g2b/9483 DnOv90SmMwvHyGrDiKr3ezn2whXCTGo5lANTbb+SV6V8frUAkeCKUQAmXXFAo3Uc4AOvoTq9i8l +HlBhQR24sFrxd7rR3rdv83icHcry54AbUm0oNdHtSihFngI9h73lAlV7NVCd0Ybj7OGIpy2eA= = X-Received: by 2002:a05:6000:4029:b0:3f2:b077:94bc with SMTP id ffacd0b85a97d-4256713a783mr7094462f8f.4.1759831824704; Tue, 07 Oct 2025 03:10:24 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHIo9lsqEhGt+dgDY2xw4UQbq2ooG2V4UY7dStIcZ9u+x44NUrjJdYXcle0yDbP6BholcgLYg== X-Received: by 2002:a05:6000:4029:b0:3f2:b077:94bc with SMTP id ffacd0b85a97d-4256713a783mr7094441f8f.4.1759831824172; Tue, 07 Oct 2025 03:10:24 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4255d8abe9bsm25059794f8f.22.2025.10.07.03.10.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Oct 2025 03:10:23 -0700 (PDT) Date: Tue, 7 Oct 2025 12:10:22 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v12 3/9] arp/ndp: send ARP announcement / unsolicited NA when neigbour entry added Message-ID: <20251007121022.353a44fc@elisabeth> In-Reply-To: References: <20251003003412.588801-1-jmaloy@redhat.com> <20251003003412.588801-4-jmaloy@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: MUu4jzNGqQHBImjpgNekNwhvbpr2Mc82gwi0rCqgmT4_1759831825 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: LWCNIYF2FWF6EZI5IOQUPTPCY3QI6FFQ X-Message-ID-Hash: LWCNIYF2FWF6EZI5IOQUPTPCY3QI6FFQ X-MailFrom: sbrivio@redhat.com 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: On Fri, 3 Oct 2025 14:41:56 +1000 David Gibson wrote: > On Thu, Oct 02, 2025 at 08:34:06PM -0400, Jon Maloy wrote: > > ARP announcements and unsolicited NAs should be handled with caution > > because of the risk of malignant users emitting them to disturb > > network communication. > > > > 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. > > > > When sending this type of messages, we notice that the guest accepts > > 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. > > > > This commit adds this functionality. > > > > Signed-off-by: Jon Maloy > > > > --- > > v10: -Made small changes based of feedback from David G. > > v11: -Moved from 'Gratuitous ARP reply' model to 'ARP Announcement' > > 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(+) > > > > 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 = 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 = htons(ARPOP_REQUEST); > > + annc.ah.ar_hrd = htons(ARPHRD_ETHER); > > + annc.ah.ar_pro = htons(ETH_P_IP); > > + annc.ah.ar_hln = ETH_ALEN; > > + annc.ah.ar_pln = 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)); > > As noted in several earlier revisions, having sip == tip (but with > different mac addresses) looks odd. Is that what the RFCs say to do > for ARP announcements? > > > + 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 { > > > > 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); > > > > #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" > > > > /* Empheral port range: values from RFC 6335 */ > > static in_port_t fwd_ephemeral_min = (1 << 15) + (1 << 14); > > @@ -140,6 +142,20 @@ void fwd_neigh_table_update(const struct ctx *c, const union inany_addr *addr, > > > > 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; > > 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. I guess those entries make sense if we can drop all these checks as a result. I think we should be able to. But if we can't, then yes, let's just go with explicit checks everywhere, so that it's consistent. -- Stefano