this is the result of my traceroute
traceroute 211.140.5.120
1 141.1.31.2 (111.1.31.2) 0.397 ms 0.380 ms 0.366 ms
2 141.1.28.38 (111.1.28.38) 3.999 ms 3.971 ms 3.982 ms
3 142.11.124.193 (112.11.124.133) 1.315 ms 1.533 ms 1.455 ms
4 (201.141.0.261) 2.615 ms 2.749 ms 2.572 ms
5 (201.141.0.82) 2.705 ms 2.564 ms 2.680 ms
6 (201.118.231.14) 5.375 ms 5.126 ms 5.252 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
I want to know what does the *** mean and does the result mean there are really more than 30 hops between my host and the target server ?
All implementations of traceroute rely on ICMP (type 11) packets being sent to the originator.
This program attempts trace route by launching UDP probe packets with a small ttl (time to live) then listening for an ICMP "time exceeded" reply from a gateway. It starts probes with a ttl of one and increase by one until we get an ICMP "port unreachable" (which means we got to "host") or hit a max (which defaults to 30 hops & can be changed with the -m flag). Three probes (change with -q flag) are sent at each ttl setting and a line is printed showing the ttl, address of the gateway and round trip time of each probe( so three * ). If there is no response within a 5 sec. timeout interval (changed with the -w flag), a "*" is printed for that probe.
So in your case we can conclude that we got response only upto 201.118.231.14. Afterwards the nodes are not responding to the ICMP packets (type 11) upto hop 30 which is the max time-to-live (max number of hops). You can increase max-time-to-live using -m flag.
Traceoute requires a response from the target server and each of the intermediate hops to create its output. If a router doesn't generate a
Time-to-live exceeded
response, traceroute will not know anything about that hop. A hop that outputs* * *
means that the router at that hop doesn't respond to the type of packet you were using for the traceroute (by default it's UDP on Unix-like and ICMP on Windows).If you are using the same version of traceroute I have you can try using the
-e
option to try to evade firewalls and the-P
option to use ICMP, TCP or GRE packets instead of UDP. You can also try specifying a particular port that is unlikely to be filtered (such as 80 or 25) using the-p
option.There may be other options that help you get a response back. Check the man page for traceroute.
To answer the second part of your question, no, this traceroute does not mean that there are exactly 30 hops between you and the target server. Traceroute "gives up" after a certain number of hops. This done by limiting the maximum TTL in the packets which, by default on Linux, is 30. You can change this with the
-m
option. There may be more or fewer hops but since none of them after the 6th one are responding, we just don't know.