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=202502 header.b=ZGtDtLLW; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id B535B5A026F for ; Fri, 04 Apr 2025 13:11:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202502; t=1743765091; bh=WGQMxyR0zbUVpd2IkhNsoeG9Dd3mC89n9biYKX5z8Y0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZGtDtLLWMxsMj07m3vVWA57qyH2qdvRn056hw0fMS/cny6aD3n6l7NSXVKDhm3oZE ZheYtZZ/PsRHP691CDB/F7JZxl90C8dg2Y8eOBXOiVu6Pem6fgM6MbZfbrm19VVp68 Mg45QKC+zlKpw+bd1VSJjOpqBAJD0qrEZl0u7zsuZAvV1IhKMOz1XUq0NEu4K9B2kp gTyyor4PA5zwR9DohocsvTofa9NPabd9KHQ/3ik92C9ZRkLF5Er2kUBoqIO+8MPtrz lEPIXJaptQMa4ese2PGxswKvqSGuoDKqNgd7Rh4aytO3jizq/7w3RYeXtSrI6OaV9z uYv0lwqCefv5g== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4ZTbX32QmVz4x8w; Fri, 4 Apr 2025 22:11:31 +1100 (AEDT) Date: Fri, 4 Apr 2025 22:11:25 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v5] udp: support traceroute Message-ID: References: <20250403222706.1036876-1-jmaloy@redhat.com> <20250404130145.57b91f6c@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="99wPgBHhJ4ORHzvm" Content-Disposition: inline In-Reply-To: <20250404130145.57b91f6c@elisabeth> Message-ID-Hash: XP2JTV5XPPZ3TJOUUQU4LNW7X6IM62DD X-Message-ID-Hash: XP2JTV5XPPZ3TJOUUQU4LNW7X6IM62DD 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: Jon Maloy , 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: --99wPgBHhJ4ORHzvm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 04, 2025 at 01:01:45PM +0200, Stefano Brivio wrote: > On Fri, 4 Apr 2025 11:57:58 +1100 > David Gibson wrote: >=20 > > On Fri, Apr 04, 2025 at 10:40:27AM +1100, David Gibson wrote: > > > On Thu, Apr 03, 2025 at 06:27:06PM -0400, Jon Maloy wrote: =20 > > > > Now that ICMP pass-through from socket-to-tap is in place, it is > > > > easy to support UDP based traceroute functionality in direction > > > > tap-to-socket. > > > >=20 > > > > We fix that in this commit. > > > >=20 > > > > Link: https://bugs.passt.top/show_bug.cgi?id=3D64 > > > > Signed-off-by: Jon Maloy =20 > > >=20 > > > Reviewed-by: David Gibson > > >=20 > > > One commont below. =20 > >=20 > > Oh.. wait. I just realised this patch has a weird side effect, for > > flows which are initiated from outside, rather than from the guest. > >=20 > > If the flow is initiated from outside, it's maybe a bit unlikely, but > > we could still get a non-default TTL from the guest on reply > > datagrams. That will trigger this code and alter the socket's TTL. > > But in this case the socket is not a flow specific socket, but the > > listening socket which initiated the flow, which could be handling > > packets on many flows. > >=20 > > The "cached" TTL is stored per-flow, not per-socket, so we won't look > > at the right value when we process datagrams from other flows, so they > > may go out with the wrong TTL. > >=20 > > I think the obvious way to address this is to stop using the > > "listening" socket to send datagrams for a flow, using a connect()ed > > socket instead. We have other reasons to do that too, and I'm working > > on implementing that right now. > >=20 > > The question is whether this is a serious enough problem to delay this > > until the "both sides connect()ed sockets" change is merged. >=20 > On the other hand, this patch applies cleanly on top of your "Use > connect()ed sockets for both sides of UDP flows" series, and also > semantically I couldn't spot any particular change or integration > that we would need as a result in this patch. Ah.. yeah. When I wrote the above I didn't think I'd finish that series today :). > I haven't reviewed the series yet, but I don't think that an eventual > re-spin would change this, so... problem solved I guess? I can just > wait and apply them together. Yeah, I guess so. Hooray! --=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 --99wPgBHhJ4ORHzvm Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmfvvlwACgkQzQJF27ox 2GfqmA/+Mo+Gp8pzN0fv2QDCRHAUsEK4azPN1YOI3Bv+x8wFH0PE/u9EXh+XWqnW 9JqkXrKhwPdFduDtTP9YlbFmyVUdehhS+WQG02+m4cSQeGy+T2DA6Q6g9um+L6iH 1EYsO2L8N72gB0eTJilI70zTcgfVdYqJOc3yNcM7F0hf03cYyX5hCte6BZGqctsY JsJcAoCeq5hA0lsCDfjF0snDU8uv4aZLga5oLZ0KBnlE3Bjk96XEhPOjz0g1CH+O gDNzbsnxh0p5XoVihXsY0mDHXWzuQgh1Zrsey6q83zf9SJja1b8tWHhaSEb6euMG DKk6llxUNZzVxZrtTDfSRCedx1ara2TZ4ltYwCAi6Y09r4gYAtqd7KU5eno1M1TQ FKyVjINhl7IZpsqmQc1B9iFwAdoPHfQXRUhWEciytBAizkIYx0ySiXyxxBfgCZVH bLzre2V4i3yYfOmfZ6hhWHpjoBbeQ1CWd6r+eRMNMqiDRLi485rI0G2Fc8pbqkqM TCckuiRyTs/+96GSmwyGlpQggKNvQb66pOijP9+xtle0ADyLhfEHY33ZHqyjOz5m 2i79H/NeiIylxXVJJtNmxPrXZDxXlNd8cHmHYm3I8eLCjZ53ygV2PaJuhz9iB6Qo p3tX8UOOC7JyP2Pj3N3CH2/nN1HMKSq+zWoPwONAckNfpX66bVo= =dwlN -----END PGP SIGNATURE----- --99wPgBHhJ4ORHzvm--