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=GaBhm6RM; 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 4D44B5A0271 for ; Tue, 05 Aug 2025 23:39:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1754429982; 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=+rWBIyWTD7boxJ/AWbnozETx7jOzi9SQaY4WrW7g/pg=; b=GaBhm6RMDx17WS7C4fHW+dPiOxSSVl79qIvp7rncVWB3AFopU1KBq1wK05eEfuVLjDlas/ MB/vH1Vdt352KqD+7jBG24ukP+Fpl70KZd4omnJO7AM+oGIfvEaqWui0FddnLNJMT436/k IJVu335ejXGDboFMZ8iMRf8hd5MjNhs= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-47-ObWVmvyoMZi0EJJUdI_lfQ-1; Tue, 05 Aug 2025 17:39:40 -0400 X-MC-Unique: ObWVmvyoMZi0EJJUdI_lfQ-1 X-Mimecast-MFC-AGG-ID: ObWVmvyoMZi0EJJUdI_lfQ_1754429979 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-459d665a87aso16661165e9.1 for ; Tue, 05 Aug 2025 14:39:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754429979; x=1755034779; 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=+rWBIyWTD7boxJ/AWbnozETx7jOzi9SQaY4WrW7g/pg=; b=Deh6YmUi/XPiJy0/k/HjulTl68/r6NMe0saBNyxT2yCzXIie7rUrhjnxwT5CzCSuJn +rVPgFzzBpV27NbznqszLIELAXl+6/d6LZfYjSVBvPauiY5pOlgpULLoMvKLo7K27QQv 6z4GNDeECJyr1huCR3oOqRXNPrNFQWopCFYkltJdY0AxryV87GPHW5Ef39bDQ9abSnOJ SQU2tTi5Gh2tnmNApqUjSq/gLSst+44Q2Xdmj9W6Cc0cXHlVn2QNTkmbFUr7P7NkzIuZ ima8QjbQPsG45W0m6eqj2QVIgursbiDrlbaAtTrTdoWDegR+4DvEA5sZZH2XSa6BU++u ltsA== X-Forwarded-Encrypted: i=1; AJvYcCWc5aSMi/Q59tXdjmXFiY64skFOGP2ujARuNFqqn8B/1hOmXUuTpz2Sz7ODsZAqy/Iq0HtkSAXGQm4=@passt.top X-Gm-Message-State: AOJu0YxvF86FfCRfMdUhh5t38w0hzDjJO1E/I0N0ZUEXbXkEognxOxY7 9wECCzcBvTND4u4VWkanfOlmKMRfy0eqFDHoMlQCenFpuDdyENdqNWkNO1/FHan6j6I9qcLuVWz xUIPZ3Z5bfXQ4/dOLLNvonbTRwqWoIdzHd+FKS+NQg3GWtF+FxxLJ5Q== X-Gm-Gg: ASbGncssYlQGOHsEjQ9wXjmsaXjCN5ey7mKQyUb8Y1JzWVXxTWUu4WkdBAX0b+34Rig SS1aZm75zlyqcLve9YOlQ5kXOEno9xghBMZBRmxKaPn8SMNneT0jMlgBwJvyZszgTqn/KY+hYGK Zj3cXYLiHpLGVrG4GAGq6giFwg3ysI760Bq8bukGF+gvcwgR6MCm3d92AyTNJ/2N58Tehy9dsab N8xOF78G5dVnhgsjWqRSa5Dr2xeQe0rIfMhwmbgR0QNhaWPzCb3STTtAjCwdC5687sZ8plOTewb H+RPXcxCDdznbMtXjXXu2izFejr/X79bG7EwogHbGPDD/axesvavFIoSMK2BxxvoynZp X-Received: by 2002:a05:600c:1994:b0:456:e39:ec1a with SMTP id 5b1f17b1804b1-459e744f720mr1857115e9.14.1754429978742; Tue, 05 Aug 2025 14:39:38 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGFJ2aaa2EayUmGtrxWbtiBxgQcoG9GN1+AYJ06sVdO2xwmjzjdv6Cmf2GpKVH/beofUhwWog== X-Received: by 2002:a05:600c:1994:b0:456:e39:ec1a with SMTP id 5b1f17b1804b1-459e744f720mr1856935e9.14.1754429978229; Tue, 05 Aug 2025 14:39:38 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-458bd5a0f9bsm88283755e9.0.2025.08.05.14.39.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Aug 2025 14:39:37 -0700 (PDT) Date: Tue, 5 Aug 2025 23:39:35 +0200 From: Stefano Brivio To: Jon Maloy Subject: Re: [PATCH v3 2/8] arp/ndp: respond with true MAC address of LAN local remote hosts Message-ID: <20250805233935.71fa4678@elisabeth> In-Reply-To: References: <20250629171348.86323-1-jmaloy@redhat.com> <20250629171348.86323-3-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: zlbCbYt8TfcwKFOFyEy3_MmnRuDYMfNXSki5NjJg2oU_1754429979 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: LUG4LMQMDC67ZH5WSWJHAKNIHQIC4TFS X-Message-ID-Hash: LUG4LMQMDC67ZH5WSWJHAKNIHQIC4TFS 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: David Gibson , 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 Tue, 5 Aug 2025 16:00:53 -0400 Jon Maloy wrote: > On 2025-07-21 21:55, David Gibson wrote: > > On Sun, Jun 29, 2025 at 01:13:41PM -0400, Jon Maloy wrote: > >> When we receive an ARP request or NDP neigbor solicitation over > >> the tap interface for a host on the local network segment attached > >> to the template interface, we respond with that host's real MAC > >> address. > >> > >> The local host, which is acting as a proxy for the default gateway, > >> is still exempted from this rule. > >> > >> Signed-off-by: Jon Maloy > >> > >> --- > >> v3: - Added helper function to find out if a remote ip address is subject > >> to NAT. This filters out local host addresses which should be > >> presented with the passt/pasta local MAC address 9a:55:9a:55:9a:55 even > >> though it is on the local segment. > >> - Adapted to the change in nl_mac_get() function, so that we now consider > >> only the template interface when checking the ARP/NDP table. > >> --- > >> arp.c | 9 +++++++++ > >> fwd.c | 2 +- > >> fwd.h | 3 ++- > >> inany.c | 15 +++++++++++++++ > >> inany.h | 1 + > >> ndp.c | 9 +++++++++ > >> 6 files changed, 37 insertions(+), 2 deletions(-) > >> > >> diff --git a/arp.c b/arp.c > >> index fc482bb..1952a63 100644 > >> --- a/arp.c > >> +++ b/arp.c > >> @@ -29,6 +29,7 @@ > >> #include "dhcp.h" > >> #include "passt.h" > >> #include "tap.h" > >> +#include "netlink.h" > >> > >> /** > >> * arp() - Check if this is a supported ARP message, reply as needed > >> @@ -40,6 +41,7 @@ > >> int arp(const struct ctx *c, const struct pool *p) > >> { > >> unsigned char swap[4]; > >> + union inany_addr tgt; > >> struct ethhdr *eh; > >> struct arphdr *ah; > >> struct arpmsg *am; > >> @@ -72,6 +74,13 @@ int arp(const struct ctx *c, const struct pool *p) > >> memcpy(am->tha, am->sha, sizeof(am->tha)); > >> memcpy(am->sha, c->our_tap_mac, sizeof(am->sha)); > >> > >> + /* Respond with true MAC address if remote host is on > >> + * the template interface's network segment > >> + */ > >> + inany_from_af(&tgt, AF_INET, am->tip); > >> + if (!inany_nat(c, &tgt)) > >> + nl_mac_get(nl_sock, &tgt, c->ifi4, am->sha); > >> + > > > > Hmm. Here's one concern about the overall concept here. If neither > > the guest nor the host has contacted this neighbour before, it > > probably won't be in the host's arp/neighbour table so this lookup > > will fail, and we'll use our_tap_mac. The guest then contacts it, so > > the host ARPs it. When the guest's ARP times out, it re-ARPs and this > > time gets the actual MAC address. i.e. it seems to me this approach > > may substantially increase the odds of the guest seeing a peer change > > MAC. Not sure if that's a problem. > > I notice this recurring concern from you, but I see no suggestion for > how to handle it. Could I try to trigger a host ARP call, e.g., by > sending a preceding ping when certain conditions are fulfilled, or are > you saying the series is meaningless? We discussed this concern with David in a call a while ago, and I guess I owe you a summary (sorry for not following up). Some tentative (somewhat debatable but probably reasonable) outcomes were: 1. the most important use case for the feature you're implementing is for inbound connections (remember the PiHole thing...?), and in that case, the MAC address of the peer just appeared in the ARP table, supposedly, so that should already work 2. for outbound connections, that's not the case, and the MAC address might actually be missing. In that case, we pick our_tap_mac when the flow is established, and perhaps we should just keep using that for the whole duration of the flow? 3. the guest seeing a MAC address change for a given IP address shouldn't be a problem (normative references don't say anything about it, as far as I can tell, and it's something that happens in common cases), but it still feels saner to stick to a given MAC address for a given flow (even if at some point we have more updated information about a peer) 4. adding probes sounds worse than the original problem because: a. we introduce spurious, potentially confusing, spurious traffic, and that's something we always avoided, in the name of "transparency" b. ICMP won't necessarily work c. even if it does, you don't know how long it takes, and delaying flows for whatever amount of time might be problematic d. again, this mostly (almost entirely?) matters for inbound connections only. We don't have to implement crazy stuff for outbound connections where it practically shouldn't matter ...long story short, sticking to our_tap_mac for the whole duration of the flow _if we don't have a MAC address_ (when the flow is established) sounded like the most reasonable approach. And, if we have a MAC address, what your series does should be the right thing anyway. What do you think? -- Stefano