From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id F12F05A0082 for ; Thu, 17 Nov 2022 06:08:01 +0100 (CET) Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4NCSbc21JQz4xZ3; Thu, 17 Nov 2022 16:07:56 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1668661676; bh=GDYFkGysbq2QJlTVuNhc2xNBuVbN4yZpB9ubKwsxzPg=; h=Date:From:To:Cc:Subject:From; b=brMH0Nwgjj+TW2VyYU1sBL/vRIhBnb6ZK5dC1FcMKPaMrzSSYCkdMuiHfUG8TpazE ZxuRyy9g22p3zCbgzroYDz//pXn6MMTdzHBw2eCeJMaWtM3i/C60foyl80/XkllXP9 /GPt4p9STsbNdSfFVJJKBmbqtFx8fV2G+85p4Y4g= Date: Thu, 17 Nov 2022 16:07:32 +1100 From: David Gibson To: Stefano Brivio Subject: UDP "splicing" fairly broken :( Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="q2Aw9n1VE9SjW64U" Content-Disposition: inline Message-ID-Hash: 45HRI4VE5Y5BOVEGEHVBQPQDNFC5MWXG X-Message-ID-Hash: 45HRI4VE5Y5BOVEGEHVBQPQDNFC5MWXG 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.3 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: --q2Aw9n1VE9SjW64U Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In preparation for trying to implement dual stack sockets for UDP, I've been getting my head around how the UDP splicing works. Alas, I'm pretty sure that it's broken if there's not a one-to-one correspondence between init side source ports and ns side destination ports. That will typically be the case, but given its UDP there's no guarantee. In addition, UDP servers in the ns will not see the correct port numbers with getpeername(). That's also true of spliced TCP connections (see https://bugs.passt.top/show_bug.cgi?id=3D39), but it's more likely to matter for UDP (I don't know of any TCP protocols that care about source port number on the server side, but there are some common UDP protocols that have at least port number conventions on both sides). I can expand on the details later, but pasta will do the wrong thing in at least some circumstances for both a single init side socket sendto()ing packets to multiple different ports in the ns/guest and multiple init side sockets send()ing to the same port in the ns/guest. I think I know how to fix it, but it's not a trivial job. So, the question is do I embark on this now, or do I just remove UDP "splicing" entirely for the time being (other than a minimum required to make -U work)? That would unblock dual stack UDP sockets and we can attempt to reoptimize this later. --=20 David Gibson | 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 --q2Aw9n1VE9SjW64U Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoULxWu4/Ws0dB+XtgypY4gEwYSIFAmN1wYoACgkQgypY4gEw YSIhXg/9FAc0cONoti7fDfOlC+WD2rmWuehLKZDdntvKHLnCEMdjhbVbjqRa3XZM hOD60t+ESY+r7I8adirT0R0ZXhaw3bEj4o90gxgOUZvU5Oc4qBxo/GOexdSICKyx 4xNb2NmMiFo0qH2kNqlcLWTllamoer74c4sIBPe/Imv/AAw74QfB3MpFGvUGys7E YbWQ+hrFD3vVj03n2/0z1ulUlJ53/DG3ybk+lGodGA/Tgjz7ljMrIdGl6zFe5mj6 Ep1afcsb6omDr4xM+vcTr1omUVqiSnXPH4FOVBUivO5sB8Srx0IOM/4MoD7gjHWk x7BomV2OPSckC0OUSPfQDHaw9Z8fsY6KYu8TXqKon+dPUE5wFKHbGzos5AaZysY7 silBrFF5s3MkqCSovnYHxi3Q+ermGOkur9PF8ltOvcylgDAyzElOYTuMl/cMHrs0 vKYfw3aLe4EFjwxuRVsOM1+wBXb6aIHLYf44IdKl59xxEYTecTwq9l481liRarzV qfPLM+YcdIPzkRplNKZ14x5t5WPpXYNat+NKo5PFbaTOr/oMk5V0Xc6dnjPk5bB8 3msAFraME5OcJFv50/gMaokafb3csa1bjxeHiFGnzwe4q3jY9hxXjr9mPLQXosLv S+q5cxIf+k2qN/afT50mkdpiClE7ks2dXRPR+CtHrOvj1Flv6+8= =J7lE -----END PGP SIGNATURE----- --q2Aw9n1VE9SjW64U--