Solution to tracepath no reply

Consider tracepath as a network diagnostic tool:

tracepath peterbabic.dev

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 peterbabic.dev

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?

Initial port

I have tried all the options tracepath offers to no avail. One option is puzzling:

- p Sets 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*:

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 )

Where c is a constant number with the value around 10. Not sure why.

Conclusion

Using tracepath command to find the path to the host over the network:

tracepath host.example.com

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.

Links

• https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClqBCAS
• https://serverfault.com/questions/623996/how-to-enable-traceroute-in-linux-machine
• https://www.speedguide.net/port.php?port=33434
• https://www.educba.com/linux-tracepath/