Re: [PATCH] Send an initial ARP and NDP request to resolve the guest IP address

[Stefano Brivio <sbrivio@redhat.com>]

On Wed, 10 Sep 2025 12:33:44 +0200
Volker Diels-Grabsch <v@njh.eu> wrote:

> Dear Stefano,
> 
> Thanks for your timely review. I agree with almost everything of it.
> 
> Just a small clarification on this one:
> 
> Stefano Brivio wrote:
> > > @@ -1503,11 +1510,12 @@ void tap_backend_init(struct ctx *c)
> > >  	case MODE_PASST:
> > >  		tap_sock_unix_init(c);
> > >  
> > > -		/* In passt mode, we don't know the guest's MAC address until it
> > > -		 * sends us packets.  Use the broadcast address so that our
> > > -		 * first packets will reach it.
> > > +		/* In passt mode, we don't know the guest's MAC address until
> > > +		 * it sends us packets (e.g. responds to our initial ARP or  
> > 
> > I don't think the response is an example, so I wouldn't use "e.g."
> > here, rather "i.e." / "that is", if that's the expected behaviour.  
> 
> The reason for using "e.g." is the following: There is still the
> "usual" case where the passt client (QEMU) was freshly started
> together with passt.
> 
> In that case, it *will not* respond to neither our ARP nor NDP request,
> simply because it won't recognize the IPv4/6 addresses, because it
> doesn't yet have any.  In that situation, we'll learn about the guest's
> MAC address only after it sends a DCHP request, or NDP, or similar to
> us, on its own initiative - not as a response to anything we might
> have sent.
> 
> So I'd propose to either keep the "e.g." wording, or to extend the
> comment by enumerating all possible cases.

Ah, sorry, I see what you meant now. Of course, it makes sense.

> (Regarding the latter, I don't feel confident enough to be able to
> really enumerate them all.  In addition to DCHP, NDP NS and DHCPv6, a
> sufficient strange client network stack might even broadcast nonsense
> packets to us, which we might not process further, but still learn the
> guest's MAC address from.)

I guess the version in v4 is more terse without any real loss of
generality or clarity.

-- 
Stefano