Published: 14.04.2021 | Edited: 09.05.2021 | Tags: 100daystooffload
Solution to tracepath no reply
Consider tracepath as a network diagnostic tool:
The output might be surprising:
1?: [LOCALHOST] pmtu 1500 1: _gateway 0.748ms 1: _gateway 0.676ms 2: 192.168.66.1 1.564ms 3: no reply 4: no reply 5: no reply 6: abc.bcd.def.tld 30.697ms asymm 7 7: no reply 8: no reply 8: no reply 9: no reply 10: no reply ... 30: no reply Too many hops: pmtu 1500 Resume: pmtu 1500
Ideally, the actual path is found. Instead, the maximum number of hops is reached. The path exists however:
Traceroute returns the path in under 10 hops (TTL). Matt's traceroute outputs the equivalent:
mtr -w peterbabic.dev
Both outputs has been omitted here. The question is, why is tracepath struggling?
I have tried all the options tracepath offers to no avail. One option is puzzling:
- pSets the initial destination port to use
What does initial port mean? There is no mention of tracepath under well known ports.
Well known ports
There however exist well known ports that contain string *trace*:
|ctf||84||tcp||Common Trace Facility|
|ctf||84||udp||Common Trace Facility|
|clever-ctrace||6687||tcp||CleverView for cTrace Message Service|
|speedtrace-disc||33334||udp||SpeedTrace TraceAgent Discovery|
|mtrace||33435||udp||IP Multicast Traceroute|
|dccp-ping||dccp||ping/traceroute using DCCP|
I did not know any mentioned services, apart from traceroute. Looking around at its manual:
LIST OF AVAILABLE METHODS
default The traditional, ancient method of tracerouting. Used by default.
Probe packets are udp datagrams with so-called "unlikely" destination ports. The "unlikely" port of the first probe is 33434, then for each next probe it is incremented by one. Since the ports are expected to be unused, the destination host normally returns "icmp unreach port" as a final response. (Nobody knows what happens when some application listens for such ports, though).
This method is allowed for unprivileged users.
Provides for some interesting reading. Who knew?
The magic number 33434
Decided to try the well known traceroute port of 33434 as the initial port of tracepath:
tracepath -p 33434 peterbabic.dev
The path is found!
A range of options
It looks like the port number is incrementing starting at 33434, there should be a range. Hint at Wikipedia:
On Unix-like operating systems, traceroute sends, by default, a sequence of User Datagram Protocol (UDP) packets, with destination port numbers ranging from 33434 to 33534;
Testing with higher initial port:
tracepath -p 33499 peterbabic.dev
Finds the path still. In fact, my tests shows it works approximately according to formula:
initial port = 33534 - ( required hops + c )
c is a constant number with the value around 10. Not sure why.
Using tracepath command to find the path to the host over the network:
If the command ends with the unhelpful response:
no reply no reply no reply ... Too many hops.
Use port 33434 as an initial port:
tracepath -p 33434 host.example.com
This is a 35th post of #100daystooffload.