Re: [PATCH v12 3/9] arp/ndp: send ARP announcement / unsolicited NA when neigbour entry added

On Thu, Oct 09, 2025 at 09:29:12PM +0200, Stefano Brivio wrote:

On Thu, 9 Oct 2025 14:51:02 +1100 David Gibson wrote:

...

On Wed, Oct 08, 2025 at 12:01:18PM +0200, Stefano Brivio wrote:

...

On Wed, 8 Oct 2025 11:27:32 +1100 David Gibson wrote: [snip] but that wasn't the case, hence (I think) the current struggle. If we go in that direction, I hope it's possible.

Thinking a bit more closely, I don't think it is, for much the same reason it wasn't in this draft.

According to the rules Jon and I thrashed out elsewhere in the thread, there are certain guest side addresses that must be locked to use our_tap_mac. We're essentially shadowing something that might exist on the host side, so we should use our MAC not the MAC of whatever is shadowed.

Just pre-populating an entry won't do the trick, because it could be overwritten if the right events occur for the shadowed host.

Right, sorry, I omitted another bit of context: I've been suggesting to Jon that he'd introduce some kind of "permanent" or "administrative" bit, and keep those entries at the beginning of the chain, exactly for the reason you mention.

Ah, right. Yes, that's a good idea.

I can imagine we'll need those at some point if we ever want to offer explicit link-layer address mapping in the future, and they're probably convenient the day one can change map_guest_addr and map_host_loopback at runtime.

We can also happily skip that for the moment, though, it's another problem we can keep for later.

Right. -- 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