From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=eD8j3wzS; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id B7DC55A0262 for ; Fri, 19 Jun 2026 12:43:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1781865811; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Zmjc1owKs6r6DtCp8X2FoPZimDugqxnOJu/WWE2jSSE=; b=eD8j3wzSxvOEEj5kmmr5lyikeTwSVwy4UXaX5wmO4I6gwPNhYUDWJCKuzc20vYAfwOhsS3 YoVb5edPpDxvBjs8NCsBx0S6TACqSgLQPb/G3mPpedVPSZFxhBzeXqMzfUXeB+taFp66V6 xlo7O1nFyPBTERXPc/AB//VzkvfBFUs= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-618-3XxtZRo7N3CA6N10zfTv2A-1; Fri, 19 Jun 2026 06:43:30 -0400 X-MC-Unique: 3XxtZRo7N3CA6N10zfTv2A-1 X-Mimecast-MFC-AGG-ID: 3XxtZRo7N3CA6N10zfTv2A_1781865809 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-490b4d3d3e6so11860835e9.0 for ; Fri, 19 Jun 2026 03:43:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781865809; x=1782470609; h=date:content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Zmjc1owKs6r6DtCp8X2FoPZimDugqxnOJu/WWE2jSSE=; b=kNMH/Awtj3bLs1RwHyj+qn3doLs1cnMiFfr5dM3vYO3/Qpb4xCa6ZuJ+88v7KEfjc/ bYoaNiqodl99CxQkxJkIi39ifqVm9KJbglyU66l6zMbrrfg6c4Reu8kDDx9Dl9Y7dcuP USOCpRJEUUM9DwCmyVRhSqMNSZTEKjqJNlrQoKmuBMS1SDuUExslhwQR4u4Zgk/pgPQa Wi8V3Od3Pa6gLnDtsdy6dNZBIcPZv62JX7AxcHZVU3owRJLXKfhcLtLR2aulCmQ6yitH PZosGSw/jmMoRnDI1P+mAgtT6VBkfAK2clgrYhwQRCGFSLH5pZzGUrflpdDeq00tT904 Az/w== X-Forwarded-Encrypted: i=1; AFNElJ/2PF1QE7FYn64woigovCtzZrV1lYoVzJ4+/UiiznmrJn1vR5jR+Z6Ask5hb89LFZVwGAVZDxhlr5o=@passt.top X-Gm-Message-State: AOJu0YyIv6ErUPdUsLNzwvvfn5lpujfCuoHckz9RkKppFHK9RuLLUwvv V12CoXKfxl3EDVvBwq6/DSIPPtRWIAFZkdufEzp0KCAOYP4eRH1UYhn6fqc30wrGviys4GUmeeR okq4pcCDZTcoP4rhBiLpo8lxizMXIqt+Jijdz9hh1m7yzFXWDiEfzh4EwisBsVQ== X-Gm-Gg: AfdE7cmAziLxLj1shJBrofnxMCBIKBKi8mL+Y6lvZboxT7TgNOBc+J98h7QDkvcwudH OxfUfD1D8W+t1egpY6dCjjJ0AI4g1YnKaE3hf6VMKUw10M44b7hxNORo6AIH5uFkl9b79Rsz8m+ AF5KDOvHXwyQTfv1tzWgXUf8gEWuDkUT3u3RW1+J6B3ajZZFKZH+NJp7LKcf1qZJg9z6Gx4lS4V lbKGJfJNeadV6IkEMcP+eE5YDr+Zyrh5cB9Qj4A05GIpTcmdzlxdb7e+WsYFUNw8iaRj58ZdA4T z60Z9oJPA/OrDFf72XgD1X47aenBqCI7HVYnn23uoESksmm2Iff8x7OA6E9p2NQh/YXAjKAew4b OHeVWIsmBvcDbUFchjMuDTYag4PpMVUNXznBhkRQ= X-Received: by 2002:a05:600c:2e96:b0:490:be1e:6ce6 with SMTP id 5b1f17b1804b1-4923f14c34emr39526055e9.9.1781865808760; Fri, 19 Jun 2026 03:43:28 -0700 (PDT) X-Received: by 2002:a05:600c:2e96:b0:490:be1e:6ce6 with SMTP id 5b1f17b1804b1-4923f14c34emr39525605e9.9.1781865808118; Fri, 19 Jun 2026 03:43:28 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4923fc47720sm96455335e9.0.2026.06.19.03.43.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jun 2026 03:43:27 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH] tap: don't let overheard traffic move addr_seen when serving a fixed address Message-ID: <20260619124325.6608d0ef@elisabeth> In-Reply-To: References: <20260611042619.3704495-1-ej.campbell@gmail.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Fri, 19 Jun 2026 12:43:26 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Luig8DRg9HzkKrcUk5QGxW_S28vchrgjnd6zzMbildg_1781865809 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: B2RTIB66RD36OZRK5754GDC7XHO63NC6 X-Message-ID-Hash: B2RTIB66RD36OZRK5754GDC7XHO63NC6 X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: EJ Campbell , passt-dev@passt.top, Jon Maloy X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri, 19 Jun 2026 14:39:46 +1000 David Gibson 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