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? /jon