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=V+3ESOSC; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 4D5CD5A0275 for ; Wed, 19 Mar 2025 06:26:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202502; t=1742362006; bh=i9CT+WpHWu1qEMm6QcN2vlZrMHHtUW63RvEy1Id+qb4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=V+3ESOSCfAshP46E69xJDIyfnTI5x3vrAO2HFo8O/rnSUBzR/oMZVgjNxysZZhlb0 FEq3V2wvb4+Ud/DjG0gOEvKUqPqv5rVFFk9SKNkF8oR5q0BMpAqfAR18Kk2yARIGrp Pti3JzWm/FpQoqWj2FjdHn89p2bX4UOVBRRbWiUr/KUSgBMgJRFEe9TRFBCPKxYA9d iMdCRHVPhUr2TXBHI4i+sNHvFTou1ajpL7E08I56yP3QamjhQY+eXFa0ieKhZySYI1 CKEMZP7FPaxkpMlUDbBBTjao3u0qzaAZBieMhmrI/sOEzQkkkoMrihIzyKyPMxBSoV xpIxeak/v+lDg== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4ZHcdf6Nhqz4x2g; Wed, 19 Mar 2025 16:26:46 +1100 (AEDT) Date: Wed, 19 Mar 2025 16:26:40 +1100 From: David Gibson To: Jon Maloy Subject: Re: [PATCH 2/2] udp: support traceroute for IPv4 Message-ID: References: <20250315153245.435293-1-jmaloy@redhat.com> <20250315153245.435293-3-jmaloy@redhat.com> <2c6759d6-c58b-414d-9e94-2faac0c410a5@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="arEc4A/Tgu0JW1Pd" Content-Disposition: inline In-Reply-To: <2c6759d6-c58b-414d-9e94-2faac0c410a5@redhat.com> Message-ID-Hash: PHP4TPST6UA2HKZ4SN7GIEMW6YILNSHT X-Message-ID-Hash: PHP4TPST6UA2HKZ4SN7GIEMW6YILNSHT 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, sbrivio@redhat.com, lvivier@redhat.com, dgibson@redhat.com 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: --arEc4A/Tgu0JW1Pd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 17, 2025 at 01:40:51PM -0400, Jon Maloy wrote: >=20 >=20 > On 2025-03-16 22:58, David Gibson wrote: > > On Sat, Mar 15, 2025 at 11:32:45AM -0400, Jon Maloy wrote: > > > 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 > [...] >=20 > > > + uint8_t ttl, const struct pool *p, int idx, > > > + const struct timespec *now) > > > { > > > const struct flowside *toside; > > > struct mmsghdr mm[UIO_MAXIOV]; > > > @@ -933,6 +935,12 @@ int udp_tap_handler(const struct ctx *c, uint8_t= pif, > > > mm[i].msg_hdr.msg_controllen =3D 0; > > > mm[i].msg_hdr.msg_flags =3D 0; > > > + if (ttl <=3D 30) { > > > + if (setsockopt(s, IPPROTO_IP, IP_TTL, > > > + &ttl, sizeof(ttl)) < 0) > >=20 > > AFAIK this will set the TTL on every subsequent packet, not just the > > next one, so this isn't quite right. To use this I guess we'd have to > > store the correct TTL in the flow, and do the sockopt if it's > > different from the guest side one. >=20 > I forgot one thing at our discussion about this at our meeting. > Traceroute works by sending three packets with ttl=3D1, then > three with ttl=3D2, then three with ttl=3D3 and so forth. > For each packet sent it steps the destination port number, > starting at 33334, and in the most extreme case (assuming it > stops at ttl=3D32, which linux traceroute does in practice) > stopping at port number 33524. > The whole port range [33434:33535] is unassigned by IANA, and > no sane developer would use it for his application, for obvious reasons. >=20 > This means that every single traceroute/udp message will become > a separate flow, and there is no need to complicate things by > storing the ttl in the flow or use it as criteria. It also > means that my current approach works fine. I don't even need > to restore the ttl in the outgoing socket, since that, just > like the associated flow, is a single-shot affair. Urgh. I mean, yes it works for (the current implementation of) traceroute, but doing it like this really isn't correct for anything else that manipulates TTL. I mean, yes, traceroute is *probably* the only thing to do that, but I think we should endeavour to be more generally correct if it's not too complicated. And in this case, I don't think it's too complicated. > > Unless there's a way to set TTL > > via cmsg. Maybe there is, but I haven't spotted it in a quick glance. >=20 > I seems I can add it as ancillary data if I add a control buffer to struct > mmsghdr.msghdr. However, it is hard to see any benefit of this, given the > above. It will cost more performance on the critical code path > than the simple test I am doing now. Thinking about this more, I don't actually think setting the TTL per-packet with a cmsg is particularly useful anyway. For traceroute to a small extent - and I suspect in the unlikely case of anything else manipulating TTL - it seems like the guest is likely to use the same TTL for multiple packets in a row. That means just calling the setsockopt() when it changes from the current value should work well. --=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 --arEc4A/Tgu0JW1Pd Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmfaVY8ACgkQzQJF27ox 2GcWIg//Xvouon+XDl9AjenrCb+pDGOqwfHi3dQ9dB669gF2EerCOKDEWWn/NgYV IlSPsQrkD4aMsptsbaVB8+iNZ+v4FI/jFdPUX7B+82a6dODHPtmu5GxuvzVBZRsP rQFRADHMTIHC04i/xD52KJTThS9vQMAZdo8iR6kc1V2vjvhVr8+hJiO8foZHb/1y j64g3yB4qZ6sS7K4MfWb+DGRZk7TCH9Wj/QSs/Rbvffe7KrfD5j/9QXvMvpPvOwZ zdlgsU12xOEuDxe8qW+kyeCdVPnLuPXl1rCIFOzVRb7LUAj9P/pjehfQ/eoSmh3Z F2ChdRuFV8r+DPHxG7MNq646WKoNjNXQC+s5vI2l2JvDtgZERlLStp4TED5ZNly7 PauyZcwdjYDKoFZdFvnKbFMO9dcj+pI6enVySB1ZpcdilxNVnaInCuNMLXe7Tfwx imiu34Dj2Ureh6y5rBmmxn2c/4yISsww9Zn+y9WF1Mkq3ny7QqLO8P2VPk5HAK6l RuhXVjONNe4JLH8hvgIXdL02YrrOoniAXGcUVowetCvHnsvFciTt18uEM6I2Cnjy nKKBxEhq9YIogCTn89GRKAhY/RHor4RyJ9R+vAt1d0sGie3IXKSGXSg//qvAFWZg csMa5iOrbeO/49wX7Ipv38yS91hedeKv/r8vaeqvi2hCV2yoU0w= =lYHD -----END PGP SIGNATURE----- --arEc4A/Tgu0JW1Pd--