On Thu, 11 Jun 2026 04:26:19 +0000
EJ Campbell
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
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