For udp tracing, by default Trippy uses a fixed src port which is set from the process id and a variable dest port which is set from the sequence number, starting from 33000 and incremented for each probe, eventually wrapping at 64511 (which is u16::MAX - 2x the maximum sequence per round, gives 65535 - (512 * 2) = 64511).
By convention, many devices on the internet allow probes to ports in the range (33434..=33534) and will return an DestinationUnreachable ICMP error which can be used by traceroute to confirm that the target has ben reached.
Therefore, given Trippy does not by default use dest ports in this range for udp probes, they do not respond with any ICMP error and so Trippy cannot see that the target was reached and must therefore show the hop as unknown.
The options here are:
Do nothing. Users can change the udp port direction and/or the initial sequence number if they wish, but this assumes that users are aware of the situation and understand how and why to correct it. This typically makes Trippy look "broken" as compared to the default behaviour of other traceroute tools.
Change the default udp behaviour to be a fixed dest port (in the range above) and a variable src port. Note that this is the current default behaviour for tcp. This differs from the behaviour of other traceroute implementation for udp and is a breaking change for Trippy.
Change the initial sequence (for udp, or perhaps for everything) to be 33434 and ensure the sequence number wraps at 33534. This is problematic as the "window" is only 100 ports wide, which is less than the theoretically max ttl (255) and also invalidates several constraints the tracing strategy currently upholds, such as ensuring that (i) 2x the number of sequence numbers can be used per-round to account for probe re-issues and (ii) sequence numbers will not be reused within two round to avoid long delayed-packets being incorrectly associated with the wrong round.
Note: a probe "re-issue" occurs when a probe cannot be dispatched as the socket cannot be bound to a given local socket address, typically as the port is already in use. In such cases Trippy will "skip" the problematic port and "re-issue" the probe with the next sequence number. In reality this is only an issue for tcp probes (which use variable src ports that must be bound to the socket) but may also effect udp for non-raw mode.
For udp tracing, by default Trippy uses a fixed src port which is set from the process id and a variable dest port which is set from the sequence number, starting from
33000and incremented for each probe, eventually wrapping at64511(which isu16::MAX- 2x the maximum sequence per round, gives65535 - (512 * 2) = 64511).By convention, many devices on the internet allow probes to ports in the range
(33434..=33534)and will return anDestinationUnreachableICMP error which can be used by traceroute to confirm that the target has ben reached.Therefore, given Trippy does not by default use dest ports in this range for udp probes, they do not respond with any ICMP error and so Trippy cannot see that the target was reached and must therefore show the hop as unknown.
The options here are:
33434and ensure the sequence number wraps at33534. This is problematic as the "window" is only 100 ports wide, which is less than the theoretically max ttl (255) and also invalidates several constraints the tracing strategy currently upholds, such as ensuring that (i) 2x the number of sequence numbers can be used per-round to account for probe re-issues and (ii) sequence numbers will not be reused within two round to avoid long delayed-packets being incorrectly associated with the wrong round.Note: a probe "re-issue" occurs when a probe cannot be dispatched as the socket cannot be bound to a given local socket address, typically as the port is already in use. In such cases Trippy will "skip" the problematic port and "re-issue" the probe with the next sequence number. In reality this is only an issue for tcp probes (which use variable src ports that must be bound to the socket) but may also effect udp for non-raw mode.