Re: [PATCH] tap: don't let overheard traffic move addr_seen when serving a fixed address

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2868 bytes --]

On Thu, Jun 11, 2026 at 04:26:19AM +0000, EJ Campbell wrote:
> Hi Stefano, David,
> 
> Thanks for the careful review. David, good to know this is a known
> gap and not just my unusual topology.
> 
> You both made the same point: --no-dhcp was the wrong condition.
> Agreed. v2 below keys on -a / --address having been given explicitly:
> a new per-family addr_fixed flag, set where -a is parsed, and the tap
> handlers skip the addr_seen updates when it's set.

Keying off -a is certainly much better than depending on --no-dhcp.
It's probably fine in practice, at least for now.  It still doesn't
make a whole lot of logical sense to me.

The question here is whether we support the guest picking an address
other than what we told it: why should that depend on where the
address we told it came from (command line versus host netlink)?  I
guess wanting to enforce that the guest uses the given address would
be somewhat correlated with wanting to specify an explicit addres, but
they don't seem inherently linked to me.

Of course, as I've said before, I tend to think supporting the guest
just picking a random address was always a mistake, but it's
established behaviour now.

> Stefano, on your other points:
> 
>   - IPv6: the global-address updates now get the same guard. I left
>     addr_ll_seen tracking alone, since a global -a says nothing about
>     which link-local address the guest picked.
> 
>   - The "behaviour unchanged" code comments are gone; that reasoning
>     lives in the commit message now.
> 
>   - Whitespace: sorry about that; my mail client flattened the tabs
>     in v1. This one comes straight from git send-email and applies
>     cleanly here.
> 
> David, on --no-address-snooping: happy to do a v3 with an explicit
> knob if you'd prefer, but keying on -a covered my case and keeps the
> option count down.

Yeah, I don't know.  As above, I feel that makes more logical sense.
But I'll admit as an explicit option it's pretty clunky.

> One more data point since v1: I caught the failure in the act with
> --trace. After overhearing the namespace kernel's broadcasts (ARP
> probes, IGMP joins, sourced from the bridge's address), pasta's
> inbound splice dials the bridge instead of the -a address:
> 
>   Flow 0 (TCP connection (spliced)):
>     HOST [127.0.0.1]:57280 -> [127.0.0.2]:22844
>       => SPLICE [0.0.0.0]:0 -> [10.0.2.1]:80    <- bridge addr, not -a
>   Flow 0 (TCP connection (spliced)): Error event on socket: Connection refused
> 
> With the patch, a reproducer that failed one run in three (99 spliced
> connections per run) passed six consecutive runs.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]