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

[Stefano Brivio <sbrivio@redhat.com>]

On Fri, 19 Jun 2026 14:39:46 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

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

I guess it's harmless and useful enough as to make that a good idea (at
least for the moment, see further considerations below), so I would be
inclined to apply this for the moment.

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

Because, I think, if the user specifies an address, that's a strong
indication that they want the container or guest to use a specific
address, and, further:

- for passt, they very likely expect guests to run a DHCP or DHCPv6
  client (why would they use -a otherwise?)

- for pasta, that's the specific address that we assign anyway at that
  point

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

As I probably mentioned a couple of times, this project wouldn't even
exist if we didn't support that, because we needed and need that for
compatibility with continuous integration systems of projects using it,
so defining whether it was a mistake or not is kind of complicated.

Besides, compatibility looks like a good idea anyway, and supporting
that means compatibility with guests without a DHCP (rare) or DHCPv6
(more common) client.

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

Thanks, sure, that makes sense.

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

I think we shouldn't add another option for a behaviour that no user
would realistically _need_ to disable, especially because I think we
have good chances to improve this in the near future, using Jon's work.

Once we get support for a generic list of addresses with attributes, we
can easily represent the fact that an address was _assigned_ (via
DHCP or DHCPv6), not just observed or configured.

If a container or guest asks us for an address and we supply one,
that's a much stronger indication that that's the right address to use
regardless of -a. (as long as we stick to a single assigned address,
which would need to change should we ever add support for multiple
guests / containers in a single passt / pasta instance).

So at that point we could decide to prefer assigned addresses to
observed ones, or in any case we'll probably be able to replace this
change with something more fine-grained.

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

-- 
Stefano