Re: [PATCH v3 2/8] arp/ndp: respond with true MAC address of LAN local remote hosts

[Jon Maloy <jmaloy@redhat.com>]

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 <jmaloy@redhat.com>
>>
>> ---
>> 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