How to Identify an Operating System Using the TTL Value in Ping
Simply put, TTL stands for Time to Live, meaning its lifespan.
First, it should be noted that the ping command uses the network-layer protocol ICMP, so TTL refers to the lifespan of a network-layer data packet. If you don’t understand this, go back and review the OSI 7-layer model.
The first question: why does the concept of a lifespan exist? Obviously, a packet traveling from one machine to another must traverse a long path. This path is clearly not straightforward; it is complex and quite likely to involve loops. If a data packet enters a loop during transmission and is not terminated, it will keep circulating forever. If many packets keep looping like this, it would be a disaster for the network. Therefore, a value needs to be set within the packet, and each time the packet passes through a node, this value is decreased by 1. Repeating this process can ultimately lead to two outcomes: the packet reaches its destination while this value is still positive, or after passing through a certain number of nodes, the value reaches 0. The former represents a successful normal transmission, while the latter means the packet may have taken a very long path or even entered a loop, which is obviously not what we want. Therefore, when this value becomes 0, network devices will no longer forward the packet but will directly discard it and send a notification back to the source address, saying the packet is dead. In itself, the TTL value doesn’t represent much. For the user, the concern should be whether the packet reached its destination, not how many nodes it passed through. However, TTL values can still yield interesting information. Each operating system defines the TTL value differently, and this value can even be modified by changing certain system network parameters. For example, Win2000 defaults to 128, but it can be changed via the registry, while Linux is mostly defined as 64. Generally speaking, however, very few people bother to modify this value on their machines, giving us an opportunity to roughly determine a machine’s operating system through the TTL echoed back by ping.
Taking two machines in my company as an example, look at the following commands: D:/Documents and Settings/hx>ping 61.152.93.131 Pinging 61.152.93.131 with 32 bytes of data: Reply from 61.152.93.131: bytes=32 time=21ms TTL=118 Reply from 61.152.93.131: bytes=32 time=19ms TTL=118 Reply from 61.152.93.131: bytes=32 time=18ms TTL=118 Reply from 61.152.93.131: bytes=32 time=22ms TTL=118 Ping statistics for 61.152.93.131: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss Approximate round trip times in milli-seconds: Minimum = 18ms, Maximum = 22ms, Average = 20ms D:/Documents and Settings/hx>ping 61.152.104.40 Pinging 61.152.104.40 with 32 bytes of data: Reply from 61.152.104.40: bytes=32 time=28ms TTL=54 Reply from 61.152.104.40: bytes=32 time=18ms TTL=54 Reply from 61.152.104.40: bytes=32 time=18ms TTL=54 Reply from 61.152.104.40: bytes=32 time=13ms TTL=54 Ping statistics for 61.152.104.40: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss Approximate round trip times in milli-seconds: Minimum = 13ms, Maximum = 28ms, Average = 19ms The first machine has a TTL of 118, so we can basically determine that it is a Windows machine, with the packet passing through 10 nodes from my machine to it, because 128-118=10. The second one should be a Linux machine, for the same reason: 64-54=10. After understanding the above, some people might have questions, such as the following: 1. Isn’t it said that packets can take many paths? Why do I see the same TTL for all 4 packets, with no variation? This is because the path a packet takes is determined by some optimal selection algorithms. After the network topology stabilizes for a while, the packet’s routing path also relatively stabilizes on a shortest path. How this is calculated involves routing algorithms and is beyond the scope of this discussion. 2. For the second machine in the example above, why isn’t it considered a Windows machine that went through 74 nodes? Because 128-74=54. To address this question, we need to introduce another excellent ICMP protocol tool. But first, let’s state that a packet passing through 74 nodes is somewhat terrifying; such a path is best avoided. The tool to introduce is tracert (traceroute under *nix). Let’s look at the results of using this command on the second machine above: D:/Documents and Settings/hx>tracert 61.152.104.40 Tracing route to 61.152.104.40 over a maximum of 30 hops 1 13 ms 16 ms 9 ms 10.120.32.1 2 9 ms 9 ms 11 ms 219.233.244.105 3 12 ms 10 ms 10 ms 219.233.238.173 4 15 ms 15 ms 17 ms 219.233.238.13 5 14 ms 19 ms 19 ms 202.96.222.73 6 14 ms 17 ms 13 ms 202.96.222.121 7 14 ms 15 ms 14 ms 61.152.81.86 8 15 ms 14 ms 13 ms 61.152.87.162 9 16 ms 16 ms 28 ms 61.152.99.26 10 12 ms 13 ms 18 ms 61.152.99.94 11 14 ms 18 ms 16 ms 61.152.104.40 Trace complete. From the results of this command, you can see the route taken from my machine to the server. It is indeed 11 nodes (earlier saying 10 was a mistake, I forgot to count 0; it should be 64-54+1, hehe), not a TTL of 128 passing through over 70 nodes. Now that we are here, let’s talk about some slightly more advanced aspects of these two ICMP commands. First is the ping command. Actually, ping has a parameter that lets you ignore the operating system’s default TTL value and use a self-defined value to send ICMP Request packets. For example, using that Linux machine again with the following command: D:/Documents and Settings/hx>ping 61.152.104.40 -i 11 Pinging 61.152.104.40 with 32 bytes of data: Reply from 61.152.104.40: bytes=32 time=10ms TTL=54 Reply from 61.152.104.40: bytes=32 time=13ms TTL=54 Reply from 61.152.104.40: bytes=32 time=10ms TTL=54 Reply from 61.152.104.40: bytes=32 time=13ms TTL=54 Ping statistics for 61.152.104.40: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 10ms, Maximum = 13ms, Average = 11ms D:/Documents and Settings/hx> With this command, we defined the outgoing packet TTL as 11. As we know earlier, it takes 11 nodes for me to reach that server, so this output is no different from before. Now let’s try this: D:/Documents and Settings/hx>ping 61.152.104.40 -i 10 Pinging 61.152.104.40 with 32 bytes of data: Reply from 61.152.99.94: TTL expired in transit. Reply from 61.152.99.94: TTL expired in transit. Reply from 61.152.99.94: TTL expired in transit. Reply from 61.152.99.94: TTL expired in transit. Ping statistics for 61.152.104.40: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms D:/Documents and Settings/hx> As you can see, the result is different. I defined the TTL as 10 for sending packets, and the result is “TTL expired in transit,” meaning the packet’s lifespan ended before reaching the server. Look closely at the IP address before this sentence; this IP is exactly the last IP before the server in our earlier tracert result. The packet’s TTL was reduced to 0 right here. According to our previous discussion, when the TTL reduces to 0, the device will discard the packet and send a TTL expired ICMP feedback to the source address鈥攖his result is the best proof. This once again proves that it takes 11 nodes, not over 70, from my machine to the server, hehe. Finally, let’s consolidate this knowledge. Some people might think the tracert command is very magical for discovering the routing path a packet takes. Actually, the principle of this command is exactly in our discussion above. Imagine if I send a packet with a TTL of 1 to the destination server, what would happen? According to our earlier discussion, at the first node the packet leaves from, the TTL will be reduced to 0. At that moment, this node will respond with a TTL expired feedback, which includes the device’s own IP address. Thus, we get the address of the first node in the routing path. Therefore, we continue sending packets with TTL=2, and we receive a TTL expired reply from the second node. By this logic, we discover them