[BREAKING CHANGE] Change initial sequence to be 33434

[fujiapple852]

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.

[fujiapple852]

This causes another long standing issue, where the trace can be seen to "jump" suddenly to a large ttl and then revert to a lower ttl with (greyed out) higher ttl responses.

For example, a trace trip 1.1.1.1 --udp may initially show:

Hops─────────────────────────────────────────────────────────────────────────╮
│#    Host                                             Snd     Sts     Dprt   │
│1    192.168.1.1                                      5       🟢      33112  │
│2    219.79.120.253                                   5       🟢      33113  │
│3    10.193.232.245                                   5       🟢      33114  │
│4    10.198.11.49                                     5       🟢      33115  │
│5    218.102.39.162                                   5       🟢      33116  │
│6    No response                                      5       🔴      33117  │

The target 1.1.1.1 initially ignores all probes as the dest port (set from the sequence number) is out side the range 33434..=33534 and so Trippy shows "No response" for hop 6.

As the trace progresses, the sequence number (and therefore dest port) will eventually enter the range 33434..=33534 and so the target 1.1.1.1 will return DestinationUnreachable ICMP responses.

The result is output such as the following:

╭Hops─────────────────────────────────────────────────────────────────────────╮
│#    Host                                             Snd     Sts     Dprt   │
│1    192.168.1.1                                      16      🟢      33420  │
│2    219.79.120.253                                   16      🟢      33421  │
│3    10.193.232.245                                   16      🔵      33422  │
│4    10.198.11.49                                     16      🟢      33423  │
│5    218.102.39.162                                   16      🟢      33424  │
│6    No response                                      16      🟤      33425  │
│7    No response                                      16      🟤      33426  │
│8    No response                                      16      🟤      33427  │
│9    No response                                      16      🟤      33428  │
│10   No response                                      16      🟤      33429  │
│11   No response                                      16      🟤      33430  │
│12   No response                                      16      🟤      33431  │
│13   No response                                      16      🟤      33432  │
│14   No response                                      16      🟤      33433  │
│15   1.1.1.1                                          16      🟡      33434  │

Whilst we would expect the DestinationUnreachable ICMP response to come for the probe with ttl=6, it actually comes from the probe with ttl=15 as that is the first probe with a dest port (33434) in the range that will trigger an DestinationUnreachable ICMP response from the target.

For the next round, which begins with the sequence number (and therefore dest port) still in the range, the target is discovered at ttl=6 (seq/dest=33440) as expected. However, as the trace in previous rounds got as far as ttl=15 then Trippy shows all 15 hops, but with hops 7 though 15 greyed out as they are beyond the target found in the current round at ttl=6. Therefore this what is shown:

╭Hops─────────────────────────────────────────────────────────────────────────╮
│#    Host                                             Snd     Sts     Dprt   │
│1    192.168.1.1                                      17      🟢      33435  │
│2    219.79.120.253                                   17      🟢      33436  │
│3    10.193.232.245                                   17      🟢      33437  │
│4    10.198.11.49                                     17      🟢      33438  │
│5    218.102.39.162                                   17      🟢      33439  │
│6    1.1.1.1                                          17      🔵      33440  │
│7    1.1.1.1                                          17      🔵      33441  │
│8    No response                                      16      🟤      33427  │
│9    No response                                      16      🟤      33428  │
│10   No response                                      16      🟤      33429  │
│11   No response                                      16      🟤      33430  │
│12   No response                                      16      🟤      33431  │
│13   No response                                      16      🟤      33432  │
│14   No response                                      16      🟤      33433  │
│15   1.1.1.1                                          16      🟡      33434  │

Screenshot to make it clearer:

Aside: Trippy operates a sliding windows probing protocol and sends multiple probes in parallel (with increasing ttl values) before receiving responses, up to a configured miximim window size. That is why we also see ttl=7 (seq/dest=33441) showing a response here.

Even more confusingly, the hop with ttl=15 is shown as 🟡 as it is the target and this is 16th probe we have sent for that ttl, and the previous 14 did not response. The hop with ttl=6 is shown as 🔵 it also has "phantom" packet loss for the same reason but is not the target hop. Fixed in #1226

Eventually the sequence number (and therefore dest port) will move beyond the range and therefore no further DestinationUnreachable ICMP response will be received, and so the rate of packet loss for target (ttl=6) will increase again (which seems reasonable).

This behaviour is highly confusing.

[fujiapple852]

The simple solution is to change the initial sequence to be 33434, which in turn means the dest port for UDP tracing will be 33434. Note that there is no change in the wrapping behaviour.

This solution in not perfect but is an improvement on the current situation in that:

• UDP tracing will discover the target hop from the first round more often
• UDP tracing will more often avoid the "jump" behaviour describe above which only occurs when tracing begins out of range and then enter the range not the other way around.

The sole downside is that, once the sequence number (dest port) moves beyond the range (33534 or greater) then the target hop will show "fake" packet loss. Technically this is not wrong, as the target does stop responding to probes, but it may confuse users into believing there is a problem when there is not.