On Tue, Sep 16, 2025 at 09:21:16PM +0200, Volker Diels-Grabsch wrote:
> The new wording clarifies that we (1) use the broadcast MAC address
> only until we know the actual MAC address of the guest, and (2) our
> first packets will not necessarily "reach" the guest, in the sense of
> being processed rather than dropped. (Which is why we actively send an
> initial ARP and/or NDP message, to get the guest MAC address as soon
> as possible.)
> 
> Signed-off-by: Volker Diels-Grabsch <v@njh.eu>

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

> ---
>  tap.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tap.c b/tap.c
> index 0f8ee25..399eeaa 100644
> --- a/tap.c
> +++ b/tap.c
> @@ -1512,9 +1512,9 @@ 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.  Until then, use the broadcast address
> +		 * so that our first packets will have a chance to reach it.
>  		 */
>  		memcpy(&c->guest_mac, MAC_BROADCAST, sizeof(c->guest_mac));
>  		break;
> -- 
> 2.47.3
> 

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson