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 NamePortProtocolDescription
ctf84tcpCommon Trace Facility
ctf84udpCommon Trace Facility
rtraceroute3765tcpRemote Traceroute
rtraceroute3765udpRemote Traceroute
clever-ctrace6687tcpCleverView for cTrace Message Service
speedtrace33334tcpSpeedTrace TraceAgent
speedtrace-disc33334udpSpeedTrace TraceAgent Discovery
traceroute33434tcptraceroute use
traceroute33434udptraceroute use
mtrace33435udpIP Multicast Traceroute
dccp-pingdccpping/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.