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

[Stefano Brivio <sbrivio@redhat.com>]

On Thu, 11 Jun 2026 04:26:19 +0000
EJ Campbell <ej.campbell@gmail.com> wrote:

> Subject: [PATCH v2] tap: don't let overheard traffic move addr_seen when address is explicit
> 
> When pasta's tap interface shares an L2 segment with other endpoints
> (e.g. bridged in a namespace with a VM behind a second tap), frames
> from those endpoints flood to pasta and their source addresses
> overwrite addr_seen — inbound flows are then spliced or forwarded to
> whichever address spoke last instead of the configured guest.
> 
> In such a setup the namespace kernel's own broadcasts (ARP probes,
> IGMP joins, sourced from the bridge address) race the guest's traffic
> for addr_seen, and inbound port-forwarded connections intermittently
> get RST after pasta dials the bridge address, where nothing listens:
> 
>   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
> 
> When -a / --address is given, the user has explicitly said where the
> guest is: track that decision with a new addr_fixed flag (per address
> family) and skip the addr_seen updates in the tap handlers. Behaviour
> without -a is unchanged, and IPv6 link-local tracking (addr_ll_seen)
> is unaffected — a global -a says nothing about which link-local
> address the guest chose.
> 
> With this change, a reproducer that previously failed one run in three
> (99 spliced connections per run) passed six consecutive runs.
> 
> Signed-off-by: EJ Campbell <ej.campbell@gmail.com>

Applied, thanks for following up, and welcome to the git log!

Jon, this will cause two trivial conflicts with v7 of your multiple
address series (8/13 and 9/13) in tap4_handler() and tap6_handler().

-- 
Stefano