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>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

0 files changed, 0 insertions, 0 deletions