J
Jarret W. Buse
Guest
TCP/IP Utilities: ping and traceroute
TCP/IP has utilities which allow for the testing of connectivity between two hosts. Ping and traceroute are two very useful tools. Ping can be used to test connectivity between two hosts, while traceroute can show the path between the two hosts using numerous pings.
Let’s say you want to connect to a web server and request a web page from your browser, but it doesn’t work. You can use ping to see that the web server is online.
NOTE: Some hosts will not respond to a ping command to prevent the host from hanging on a ‘Ping of Death’ (more on that later in the article).
So, you ping a server such as www.linux.org. You get an output similar to FIGURE 1.
FIGURE 1
We can see that there is a 100% packet loss. When this occurs we have one of two problems: the server may be down (possibly a connection between the hosts) or the server does not respond to pings. If a few packets are lost, but not all, then we can assume there is a connection problem between the two hosts. For instance, one route may be down or congested. Some pings get through because not all frames follow the same path every time.
If responses are sent, as shown in FIGURE 2, you can see that Google.com responds to pings.
FIGURE 2
Here you can see that the time to receive a response was anywhere from 42.1 ms to 135 ms. The important item to note is that all four packets were received from the ping.
One main item to discuss is Time-To-Live (TTL). Every frame placed on the Internet has a TTL value. Every time a frame is received by a router or other device the metric is decreased by one. When the metric reaches zero it is assumed that the frame is “lost”. At this point, the frame is dropped and an Internet Control Message Protocol (ICMP) message is sent to the sender to show the frame is “lost”. In the case of a ping, an ICMP Echo Request message is sent to a host which responds with an Echo Response message. The Echo Response message is then timed to get an average delay from the request to the response. The main purpose of the TTL is to prevent packets from wandering the Internet indefinitely and causing congestion.
NOTE: Since eight bits are assigned to the TTL, the maximum value for the TTL is 255.
To perform a traceroute, the system sends a ping with a TTL of one. When the echo response is received the data within the packet is displayed as follows:
1 74-137-116-1.dhcp.insightbb.com (74.137.116.1) 20.674 ms 20.604 ms 20.582 ms
Here we can see that the first packet was sent to a host called 74-137-116-1.dhcp.insightbb.com with an IP Address of 74.137.116.1. The three times shown are the time it took to complete the round trip from the host at the TTL and back to your system.
A new line is then created for each time the TTL is increased as shown:
1 74-137-116-1.dhcp.insightbb.com (74.137.116.1) 20.674 ms 20.604 ms 20.582 ms
2 74-137-113-157.dhcp.insightbb.com (74.137.113.157) 20.481 ms 27.242 ms 32.394 ms
3 tge0-9-0-8.lsvmkyzo-ccr01.mwrtn.rr.com (65.29.26.216) 46.666 ms 51.227 ms 51.232 ms
4 be24.clmkohpe01r.midwest.rr.com (65.189.140.162) 91.574 ms 91.579 ms 96.105 ms
5 ae-4-0.cr0.chi30.tbone.rr.com (66.109.6.68) 111.987 ms 111.989 ms 115.410 ms
6 107.14.17.147 (107.14.17.147) 119.545 ms 100.266 ms 41.436 ms
7 ae18.edge2.Chicago2.Level3.net (4.68.111.33) 46.057 ms * 43.365 ms
8 vl-3503-ve-117.ebr1.Chicago2.Level3.net (4.69.158.10) 54.801 ms 54.799 ms vl-3501-ve-15.ebr1.Chicago2.Level3.net (4.69.158.2) 62.775 ms
9 ae-6-6.ebr1.Chicago1.Level3.net (4.69.140.189) 62.779 ms 68.653 ms 73.098 ms
10 ae-2-2.ebr2.NewYork2.Level3.net (4.69.132.66) 74.813 ms 73.858 ms 82.060 ms
11 ae-46-46.ebr2.NewYork1.Level3.net (4.69.201.29) 82.003 ms ae-45-45.ebr2.NewYork1.Level3.net (4.69.141.21) 88.349 ms 88.359 ms
12 ae-62-62.csw1.NewYork1.Level3.net (4.69.148.34) 62.935 ms ae-72-72.csw2.NewYork1.Level3.net (4.69.148.38) 62.889 ms ae-62-62.csw1.NewYork1.Level3.net (4.69.148.34) 69.298 ms
13 ae-4-90.edge4.NewYork1.Level3.net (4.69.155.210) 75.906 ms ae-2-70.edge4.NewYork1.Level3.net (4.69.155.84) 57.675 ms ae-3-80.edge4.NewYork1.Level3.net (4.69.155.146) 62.620 ms
14 PAETEC-COMM.edge4.NewYork1.Level3.net (4.28.130.74) 72.208 ms 72.162 ms 51.392 ms
15 te-0-0-0-0.nycmny83iy6ig02.paetec.net (169.130.82.138) 61.328 ms 66.299 ms 66.234 ms
16 TE-0-0-0-0.BHLHPAEAH19CR01.paetec.net (169.130.83.245) 66.263 ms 66.227 ms 72.946 ms
17 vl-300.bhlhpaeah19pe01.paetec.net (169.130.104.132) 71.498 ms 78.100 ms 83.454 ms
18 209-255-196-74.ip.mcleodusa.net (209.255.196.74) 83.395 ms 56.999 ms 61.840 ms
19 * * *
20 iqc80.iqnection.com (209.92.24.80) * 65.01ms 77ms
By default 30 hops are performed (a maximum TTL of 30). If the response time takes more than five seconds, an asterisk (*) is printed. The delay may be caused by network congestion, a device which is offline or a device which does not respond to pings.
In the above traceroute output you can see that TTL 19 was too busy or set to not respond to a ping. Depending on the route there are about 20 routers or devices between my PC and the linux.org server.
Now, to discuss the Ping of Death (PoD), this is a malformed ping. When a host receives the ping it opens a connection to receive the ping information. A normal ping contains 64 bytes of data. A PoD is much larger being 64 kb or more. The default TCP/IP receive buffer is 64 kb (65,535 bytes) and a larger amount can crash a system.
The vulnerability to the PoD has been fixed since Linux kernel version 2.0.24.
To send a Ping of Death from a Linux system, do the following:
ping –s 65527 [ip_address]
NOTE: Most systems will not crash anymore from the PoD since patches have been put in place. Also, it is illegal to perform a PoD on a system which you do not own. It is best to verify that any server you have connected to the Internet be tested to make sure it is impervious to the PoD. Routers can be set to drop PoD data coming through.
You should note that the above ping command will not work. The ping command is hard coded to allow the packet size to be a maximum of 65,507. If you download the source code for the ping command you can change the maximum size and re-compile it.
NOTE: The PoD attack is considered a Denial of Service (DoS) where a server can crash and not be able to provide its services.
TCP/IP has utilities which allow for the testing of connectivity between two hosts. Ping and traceroute are two very useful tools. Ping can be used to test connectivity between two hosts, while traceroute can show the path between the two hosts using numerous pings.
Let’s say you want to connect to a web server and request a web page from your browser, but it doesn’t work. You can use ping to see that the web server is online.
NOTE: Some hosts will not respond to a ping command to prevent the host from hanging on a ‘Ping of Death’ (more on that later in the article).
So, you ping a server such as www.linux.org. You get an output similar to FIGURE 1.
FIGURE 1
We can see that there is a 100% packet loss. When this occurs we have one of two problems: the server may be down (possibly a connection between the hosts) or the server does not respond to pings. If a few packets are lost, but not all, then we can assume there is a connection problem between the two hosts. For instance, one route may be down or congested. Some pings get through because not all frames follow the same path every time.
If responses are sent, as shown in FIGURE 2, you can see that Google.com responds to pings.
FIGURE 2
Here you can see that the time to receive a response was anywhere from 42.1 ms to 135 ms. The important item to note is that all four packets were received from the ping.
One main item to discuss is Time-To-Live (TTL). Every frame placed on the Internet has a TTL value. Every time a frame is received by a router or other device the metric is decreased by one. When the metric reaches zero it is assumed that the frame is “lost”. At this point, the frame is dropped and an Internet Control Message Protocol (ICMP) message is sent to the sender to show the frame is “lost”. In the case of a ping, an ICMP Echo Request message is sent to a host which responds with an Echo Response message. The Echo Response message is then timed to get an average delay from the request to the response. The main purpose of the TTL is to prevent packets from wandering the Internet indefinitely and causing congestion.
NOTE: Since eight bits are assigned to the TTL, the maximum value for the TTL is 255.
To perform a traceroute, the system sends a ping with a TTL of one. When the echo response is received the data within the packet is displayed as follows:
1 74-137-116-1.dhcp.insightbb.com (74.137.116.1) 20.674 ms 20.604 ms 20.582 ms
Here we can see that the first packet was sent to a host called 74-137-116-1.dhcp.insightbb.com with an IP Address of 74.137.116.1. The three times shown are the time it took to complete the round trip from the host at the TTL and back to your system.
A new line is then created for each time the TTL is increased as shown:
1 74-137-116-1.dhcp.insightbb.com (74.137.116.1) 20.674 ms 20.604 ms 20.582 ms
2 74-137-113-157.dhcp.insightbb.com (74.137.113.157) 20.481 ms 27.242 ms 32.394 ms
3 tge0-9-0-8.lsvmkyzo-ccr01.mwrtn.rr.com (65.29.26.216) 46.666 ms 51.227 ms 51.232 ms
4 be24.clmkohpe01r.midwest.rr.com (65.189.140.162) 91.574 ms 91.579 ms 96.105 ms
5 ae-4-0.cr0.chi30.tbone.rr.com (66.109.6.68) 111.987 ms 111.989 ms 115.410 ms
6 107.14.17.147 (107.14.17.147) 119.545 ms 100.266 ms 41.436 ms
7 ae18.edge2.Chicago2.Level3.net (4.68.111.33) 46.057 ms * 43.365 ms
8 vl-3503-ve-117.ebr1.Chicago2.Level3.net (4.69.158.10) 54.801 ms 54.799 ms vl-3501-ve-15.ebr1.Chicago2.Level3.net (4.69.158.2) 62.775 ms
9 ae-6-6.ebr1.Chicago1.Level3.net (4.69.140.189) 62.779 ms 68.653 ms 73.098 ms
10 ae-2-2.ebr2.NewYork2.Level3.net (4.69.132.66) 74.813 ms 73.858 ms 82.060 ms
11 ae-46-46.ebr2.NewYork1.Level3.net (4.69.201.29) 82.003 ms ae-45-45.ebr2.NewYork1.Level3.net (4.69.141.21) 88.349 ms 88.359 ms
12 ae-62-62.csw1.NewYork1.Level3.net (4.69.148.34) 62.935 ms ae-72-72.csw2.NewYork1.Level3.net (4.69.148.38) 62.889 ms ae-62-62.csw1.NewYork1.Level3.net (4.69.148.34) 69.298 ms
13 ae-4-90.edge4.NewYork1.Level3.net (4.69.155.210) 75.906 ms ae-2-70.edge4.NewYork1.Level3.net (4.69.155.84) 57.675 ms ae-3-80.edge4.NewYork1.Level3.net (4.69.155.146) 62.620 ms
14 PAETEC-COMM.edge4.NewYork1.Level3.net (4.28.130.74) 72.208 ms 72.162 ms 51.392 ms
15 te-0-0-0-0.nycmny83iy6ig02.paetec.net (169.130.82.138) 61.328 ms 66.299 ms 66.234 ms
16 TE-0-0-0-0.BHLHPAEAH19CR01.paetec.net (169.130.83.245) 66.263 ms 66.227 ms 72.946 ms
17 vl-300.bhlhpaeah19pe01.paetec.net (169.130.104.132) 71.498 ms 78.100 ms 83.454 ms
18 209-255-196-74.ip.mcleodusa.net (209.255.196.74) 83.395 ms 56.999 ms 61.840 ms
19 * * *
20 iqc80.iqnection.com (209.92.24.80) * 65.01ms 77ms
By default 30 hops are performed (a maximum TTL of 30). If the response time takes more than five seconds, an asterisk (*) is printed. The delay may be caused by network congestion, a device which is offline or a device which does not respond to pings.
In the above traceroute output you can see that TTL 19 was too busy or set to not respond to a ping. Depending on the route there are about 20 routers or devices between my PC and the linux.org server.
Now, to discuss the Ping of Death (PoD), this is a malformed ping. When a host receives the ping it opens a connection to receive the ping information. A normal ping contains 64 bytes of data. A PoD is much larger being 64 kb or more. The default TCP/IP receive buffer is 64 kb (65,535 bytes) and a larger amount can crash a system.
The vulnerability to the PoD has been fixed since Linux kernel version 2.0.24.
To send a Ping of Death from a Linux system, do the following:
ping –s 65527 [ip_address]
NOTE: Most systems will not crash anymore from the PoD since patches have been put in place. Also, it is illegal to perform a PoD on a system which you do not own. It is best to verify that any server you have connected to the Internet be tested to make sure it is impervious to the PoD. Routers can be set to drop PoD data coming through.
You should note that the above ping command will not work. The ping command is hard coded to allow the packet size to be a maximum of 65,507. If you download the source code for the ping command you can change the maximum size and re-compile it.
NOTE: The PoD attack is considered a Denial of Service (DoS) where a server can crash and not be able to provide its services.
