From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202410 header.b=PC7qVcWX; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 0AEAE5A004E for ; Wed, 16 Oct 2024 10:25:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202410; t=1729067125; bh=TrwctyOrwo8FNlTVlMOg7F6cGypIiG5EeDqbHFjVrvY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PC7qVcWXUsvkMhCUkeK/9jPGCIioSkjpQ7hgwsiIuh5aoXVre3+NcqRIXYM9H5J2V izztpHyNul+C2IVZ2mwMMch2ze7iNGA3L808WyUXdmK6aZHJjj7RA9/MSUzolgdjR+ 4F3LmgEKSE3t0PDcII36lQcMltKe2Ink/tGZGH7SlbY5Z7i+fdC5IMw7shGSlsMJw2 UOrLTMwwaqOgmn4xW+JneXbXEE9tacPg2UqsJUomZ/xeqz5qI61KjWvLFwmeAcVUcI Soeet3WbYrVXqhyyrH0STJhRD9ZrELQ4nwfvbrvEqtTaza6LbdRYWbCDpKKLJL+9vK h3oH/ODL71pBA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4XT3ts697hz4x2J; Wed, 16 Oct 2024 19:25:25 +1100 (AEDT) Date: Wed, 16 Oct 2024 16:46:52 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v3 4/4] fwd: Direct inbound spliced forwards to the guest's external address Message-ID: References: <20241002054826.1812844-1-david@gibson.dropbear.id.au> <20241002054826.1812844-5-david@gibson.dropbear.id.au> <20241009150721.63af48f6@elisabeth> <20241009224433.7fc28fc7@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="48ogXL/wDBevgy/O" Content-Disposition: inline In-Reply-To: Message-ID-Hash: YAYL6UHH47ZWGH6PBG5LYMAV33VV3SE6 X-Message-ID-Hash: YAYL6UHH47ZWGH6PBG5LYMAV33VV3SE6 X-MailFrom: dgibson@gandalf.ozlabs.org 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: passt-dev@passt.top 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: --48ogXL/wDBevgy/O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 16, 2024 at 02:15:19PM +1100, David Gibson wrote: > On Thu, Oct 10, 2024 at 04:57:32PM +1100, David Gibson wrote: > > On Wed, Oct 09, 2024 at 10:44:33PM +0200, Stefano Brivio wrote: > > > On Wed, 9 Oct 2024 15:07:21 +0200 > > > Stefano Brivio wrote: > [snip] > > > > > @@ -447,20 +447,35 @@ uint8_t fwd_nat_from_host(const struct ctx = *c, uint8_t proto, > > > > > (proto =3D=3D IPPROTO_TCP || proto =3D=3D IPPROTO_UDP)) { > > > > > /* spliceable */ > > > > > =20 > > > > > - /* Preserve the specific loopback adddress used, but let the > > > > > - * kernel pick a source port on the target side > > > > > + /* The traffic will go over the guest's 'lo' interface, but by > > > > > + * default use its external address, so we don't inadvertently > > > > > + * expose services that listen only on the guest's loopback > > > > > + * address. That can be overridden by --host-lo-to-ns-lo which > > > > > + * will instead forward to the loopback address in the guest. > > > > > + * > > > > > + * In either case, let the kernel pick the source address to > > > > > + * match. > > > > > */ > > > > > - tgt->oaddr =3D ini->eaddr; > > > > > + if (inany_v4(&ini->eaddr)) { > > > > > + if (c->host_lo_to_ns_lo) > > > > > + tgt->eaddr =3D inany_loopback4; > > > > > + else > > > > > + tgt->eaddr =3D inany_from_v4(c->ip4.addr_seen); > > > > > + tgt->oaddr =3D inany_any4; > > > > > + } else { > > > > > + if (c->host_lo_to_ns_lo) > > > > > + tgt->eaddr =3D inany_loopback6; > > > > > + else > > > > > + tgt->eaddr.a6 =3D c->ip6.addr_seen; =20 > > > >=20 > > > > Either this... > > > >=20 > > > > > + tgt->oaddr =3D inany_any6; =20 > > > >=20 > > > > or this (and not something before this patch, up to 3/4) make the > > > > "TCP/IPv6: host to ns (spliced): big transfer" test in pasta/tcp ha= ng, > > > > sometimes (about one in three/four runs), that's what I mistakenly > > > > reported as coming from Laurent's series at: > >=20 > > Huh, interesting. Just got back from my leave and ran that group of > > tests in a loop this afternoon, but didn't manage to reproduce. I > > have administrivia that will probably fill the rest of this week, but > > I'll look into this as soon as I can. >=20 > I reproduced the problem on passt.top, and I have a partial idea > what's going on. As you say it's seeming like the address (addr_seen > =3D=3D addr in this case) isn't properly ready. This is over splice, but > on the tap interface, I see the container sending NS messages for its > own address - seems like it's doing DAD. But more importantly, we're > answering those NS messages with NA messages, because we answer all > NS. i.e. we're making the DAD fail. What I'm not sure of is how this > ever worked at all. --config-net makes sense, since we disable DAD, > but our test suite has always been using NDP+DHCP instead of > --config-net. >=20 > So, AFACT, we'll always fail guest DAD attempts, both IPv6, which > happens most of the time and for IPv4 via ARP, which is used much more > rarely. I think we need to be more selective in what NS or ARP > lookups we resopnd to. The question is what approach to take: Hmm... no.. there's more to this. Usually DAD requests have :: as the source address, and we *do* exclude those from getting replies. In this case though, we're getting NS requests for the assigned address from what looks like the SLAAC address. So, I do think it would be wise to explicitly exclude these: we shouldn't be giving NA responses for an address that ought to belong to the guest, even if it doesn't look like a DAD. But, I'm not sure what's triggering this. Is for some reason the DHCP address not "taking", so the container is trying to locate it on the network instead? Or _is_ this DAD, but under some circumstances rather than using :: as the source address it uses another configured address. --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --48ogXL/wDBevgy/O Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmcPU0sACgkQzQJF27ox 2GeNgA/7BCEVDC1cPVjKcOnAQYxAw96sR80l54qIbmvN/xibqBpRprm5i0YiicMW DzfTUGcThVNUBKNFVK8FXAmRe34tvRLBzuwAh44Ighs/6Ewjhfae4WARgGXSDiZI 2HFPgcvmM1a4slEKTwX7stN/yMUK7al5dIITNOO98hDO1RElLH95ygnueFauPbPq 3N+rAbm+dtT1j4DSkO5PHLGN53Y+g93J1HmmN8SxBtkwl/x/n2uUUn0rKc23ntgl S6qRJ74dAxVQqzg6F2yMg82d3YjKKGyyoN25r0+EUA454N9z0icy+so+DEFmArfT pqZKJyRjccYFpe1ay6RWGMmAp3Pve8Z2rM17ZkDjvNMjfKIZqno2xNwqUg4F0MKr FBtcQ1r6R3Fk6oZEt2QFx+oeCTg+/wt2c4dC1aD/5wEckx3vxtr+aFMr+83kdT6i NXL/rv7Z8Z9Jc5XtYAazQ06J04GXQvMp4cdIKVeatVUWemwlGfbH4O2FXu0iKdxD /PRIBaO7XOzcemdCPnr8hwB4JEP0QrcabCwhW246O304yd4S1UL3SNo8Bgg2lGLY FQztTF7sLDaESCh+D80KKesQAkn3bQxOYeldxBtoFsFWhOkZrtXVtkwLHFP0OxUT +/8PIamJT56vnPiEOfKa8L6Buar8wSVqkt8r/9E0L6l4TXxcwR0= =J1CJ -----END PGP SIGNATURE----- --48ogXL/wDBevgy/O--