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:                                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

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

Service Name Port Protocol Description
ctf 84 tcp Common Trace Facility
ctf 84 udp Common Trace Facility
di-traceware 3041 tcp di-traceware
di-traceware 3041 udp di-traceware
rtraceroute 3765 tcp Remote Traceroute
rtraceroute 3765 udp Remote Traceroute
clever-ctrace 6687 tcp CleverView for cTrace Message Service
speedtrace 33334 tcp SpeedTrace TraceAgent
speedtrace-disc 33334 udp SpeedTrace TraceAgent Discovery
traceroute 33434 tcp traceroute use
traceroute 33434 udp traceroute use
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:


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

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

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.


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

This is a 35th post of #100daystooffload.

Further reading