#13 Incorrect placement of asterisks for probe timeouts

[Tyler]

I think there's a bug in the output of traceroute v2.1.0.

$ traceroute -m 3 45.56.99.171 -n -q 6
traceroute to 45.56.99.171 (45.56.99.171), 3 hops max, 60 byte packets
 1  192.168.10.2  7.558 ms  7.516 ms  8.326 ms * * *
 2  198.19.123.1  13.768 ms  13.754 ms  16.205 ms  16.190 ms * *
 3  198.19.110.1  52.282 ms  50.843 ms  52.252 ms * *  44.707 ms

Is correct and normal... with 6 queries, we have 6 ms responses or asterisks per line.

Sometimes though, under conditions I can't yet nail down, when that last has failures, the asterisks end up in front of the host IP address:

$ sudo traceroute -m 3 45.56.99.171 -n -q 6
traceroute to 45.56.99.171 (45.56.99.171), 3 hops max, 60 byte packets
 1  192.168.10.2  8.342 ms * * * * *
 2  198.19.123.1  16.835 ms * * * * *
 3  * * * 198.19.110.1  50.561 ms * *

Still 6 asterisks/MS's, but wrong placement.

Even with the 3 hop default this is possible:

$ traceroute -m 3 45.56.99.171 -n
traceroute to 45.56.99.171 (45.56.99.171), 3 hops max, 60 byte packets
 1  * * *
 2  198.19.123.1  19.705 ms *  19.674 ms
 3  * 198.19.110.1  26.045 ms  27.674 ms

I only noticed this because I was trying to parse traceroute output so I was looking more closely...

This isn't expected behavior right?

[Dmitry Butskoy]

Tyler wrote:

Even with the 3 hop default this is possible:
|$ traceroute -m 3 45.56.99.171 -n traceroute to 45.56.99.171
(45.56.99.171), 3 hops max, 60 byte packets 1 * * * 2 198.19.123.1
19.705 ms * 19.674 ms 3 * 198.19.110.1 26.045 ms 27.674 ms |

I only noticed this because I was trying to parse traceroute output so
I was looking more closely...

This isn't expected behavior right?

Yes, it is expected behaviour.

The IP address is printed at the first answered probe in a line. When
the first answered probe is not the first probe, it means there is
already an asterisk in that line (because of an unanswered probe), so
the IP address appears after it.

Moreover, it is possible that replies sometimes come from different
addresses. In such a case, new IP address is printed each time it
differs from the one of the previous successful probe.

For example:

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  152.19.134.131  0.189 ms  0.233 ms  0.205 ms
 2  152.2.255.165  0.635 ms 152.19.255.165  0.615 ms  0.814 ms
 3  152.19.255.65  0.839 ms 152.2.255.65  0.746 ms  0.934 ms
 4  128.109.19.89  4.020 ms 128.109.1.89  4.234 ms  4.256 ms
 5  198.86.53.237  9.999 ms  9.990 ms  9.960 ms
 6  108.170.246.1  9.939 ms 108.170.246.33  11.419 ms 108.170.240.97 
11.312 ms
 7  108.170.249.65  11.071 ms 108.170.249.161  11.032 ms
142.251.52.63  10.203 ms
 8  8.8.8.8  9.893 ms  10.158 ms 142.251.70.151  11.020 ms

Note that by default traceroute sends 16 packets simultaneously. This
speeds up the work, but at the same time leads to some instability (some
routes filter "too often" probe packs, or re-route it etc.etc.etc.). If
this is a problem just use `-N 1' to send probe one per time (as was old
time before).

Regards,
Dmitry Butskoy

[Tyler]

Ok, I think I understand.

If the first n probes for a given hop don't get a response, you will have n asterisks ahead of the IP if/when it actually does respond.

This is because tracert doesn't know the IPs or response times of the hops until it gets a response back for that hop. Sometimes it's possible to get the false impression that it is discovering IPs and then pinging them.

Thanks for the clarification!