Old Faithful | Troubleshooting Linux Firewalls

There are a number of tools we have already touched on that we consider to be basic but critical. Even though many readers are already well aware of them and how to use them, we would be remiss if we did not at least list them here. These tools, which have been in use for literally decades, fall into the category of "old faithful" because they can, in extremely short order and with little technical knowledge, tell you a lot about the state of affairs with your firewall and network.

The first is telnet. Certainly other tools such as strobe, nc, nmap, and others can initiate tcpconnect calls, but telnet tends to be simple, straightforward to use, and something we suspect many of our readers are already familiar with. If it's not already obvious for what you would use telnet, we recommend that you call on telnet to help you diagnose quickly if you can connect to a remote TCP server. Again, there are other tools such as nmap that can launch multiple connections, using different means of connecting and also can connect to UDP services, but telnet still remains the simplest to use in our opinion. No switches or knowledge is requiredjust the hostname or IP address and the port to which to connect, for example

 telnet www.gotroot.com 80 Trying 205.241.45.98... Connected to plesk.shinn.net (205.241.45.98). Escape character is '^]'. ^] telnet> quit Connection closed.

This would connect to the HTTP port (80) on www.gotroot.com.

Our next "old faithful" tool is ping. If you are not already familiar with ping, this tool is used to generate ICMP packets to determine if a remote host is up and if packets to that host are being lost. For instance, as you may already know, to ping a host (in this case 10.10.10.192), you would first ping your own interface to make sure it is up:

 ping 10.10.100.2 PING 10.10.100.2 (10.10.100.2) 56(84) bytes of data. 64 bytes from 10.10.100.2: icmp_seq=1 ttl=64 time=0.075 ms 64 bytes from 10.10.100.2: icmp_seq=2 ttl=64 time=0.060 ms 64 bytes from 10.10.100.2: icmp_seq=3 ttl=64 time=0.072 ms 64 bytes from 10.10.100.2: icmp_seq=4 ttl=64 time=0.054 ms --- 10.10.100.2 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3000ms rtt min/avg/max/mdev = 0.054/0.065/0.075/0.010 ms

After you have determined that your network interface is functioning, you can proceed with pinging a remote host.

 $ ping 10.10.10.192 PING 10.10.10.192 (10.10.10.192) 56(84) bytes of data. 64 bytes from 10.10.10.192: icmp_seq=1 ttl=59 time=288 ms 64 bytes from 10.10.10.192: icmp_seq=2 ttl=59 time=361 ms 64 bytes from 10.10.10.192: icmp_seq=3 ttl=59 time=321 ms 64 bytes from 10.10.10.192: icmp_seq=4 ttl=59 time=362 ms 64 bytes from 10.10.10.192: icmp_seq=5 ttl=59 time=257 ms 64 bytes from 10.10.10.192: icmp_seq=6 ttl=59 time=278 ms 64 bytes from 10.10.10.192: icmp_seq=7 ttl=59 time=328 ms --- 10.10.10.192 ping statistics --- 7 packets transmitted, 7 received, 0% packet loss, time 6008ms rtt min/avg/max/mdev = 257.770/314.176/362.035/37.688 ms

As you can see in the previous examples, the host's interfaces are up. In addition to that information, ping also tells us information such as the latency of the connection to the host's network interfaces. That information is provided in the time= field. Each iteration is a specific snapshot of the latency of the connection for that ICMP packet. In the present example, that latency changes slightly between each packet. To determine the total average latency of the connection, you would cancel the ping request by selecting Control-C, and ping would compute the average time for each packet in the summary statement upon exiting. An example of ping in action against the host 10.10.10.192 follows:

 7 packets transmitted, 7 received, 0% packet loss, time 6008ms rtt min/avg/max/mdev = 257.770/314.176/362.035/37.688 ms

ping can also be used to "flood" a network connection to determine what its network capacity is and to more thoroughly determine if the network is dropping packets, if it's overloaded, or if some piece of equipment along the way is problematic. This setting will send ICMP pings as fast as possible to the host, possibly saturating your network linkso use it with caution. It is, however, a useful tool for determining if you have some hardware or congestion problems that are causing packet loss. To use the flooding capabilities of ping, you will need to be root, or you can set the SUID bit on the ping binary, although we do not recommend doing this with ping. It may introduce a security vulnerability.

After you have root access on your system, you simply pass ping the -f flag as in the following example:

 ping -f 10.10.10.192 PING 10.10.10.192 (10.10.10.192) 56(84) bytes of data. .............................................................. --- 10.10.10.192 ping statistics --- 79 packets transmitted, 17 received, 78% packet loss, time 1204ms rtt min/avg/max/mdev = 238.304/643.103/955.894/246.771 ms, pipe 62, ipg/ewma 15.446/722.229 ms

As you can see in this example, the target host 10.10.10.192 lost 78% of the packets sent to it. That tells us that something is wrong with the connection to that host, as 78% is an extremely high number of lost packets.

ping also can be used to determine the route a packet takes as it moves to its target. Again using 10.10.10.192 as an example, ping will be used to determine the route:

 ping -R 10.10.10.192 PING 10.10.10.192 (10.10.10.192) 56(124) bytes of data. 64 bytes from 10.10.10.192: icmp_seq=1 ttl=59 time=225 ms NOP RR:     10.10.100.2         10.10.10.253         10.10.10.192 64 bytes from 10.10.10.192: icmp_seq=2 ttl=59 time=231 ms NOP     (same route) 64 bytes from 10.10.10.192: icmp_seq=3 ttl=59 time=241 ms NOP     (same route) 64 bytes from 10.10.10.192: icmp_seq=4 ttl=59 time=243 ms NOP     (same route) 64 bytes from 10.10.10.192: icmp_seq=5 ttl=59 time=201 ms NOP     (same route) 64 bytes from 10.10.10.192: icmp_seq=6 ttl=59 time=210 ms NOP     (same route) 64 bytes from 10.10.10.192: icmp_seq=7 ttl=59 time=225 ms NOP     (same route) 64 bytes from 10.10.10.192: icmp_seq=8 ttl=59 time=194 ms NOP     (same route) --- 10.10.10.192 ping statistics --- 8 packets transmitted, 8 received, 0% packet loss, time 7008ms rtt min/avg/max/mdev = 194.399/221.710/243.789/16.886 ms

ping will also do some sanity checking on the reply packets for you. It will check for duplicate and damaged packets. If ping reports a duplicate packet, this might indicate that there is a link level problem somewhere in the route between your host and the remote host. Duplicate packets should never occur normally, but low numbers of them are not necessarily an indication of a serious problem. Unlike duplicate packets, damaged packets are always a sign of something serious being wrong in the network patch. Damaged packets only occur when a device is badly mangling the data moving through it. If you detect damaged packets, you should traceroute the connection and begin testing each device along the path, from multiple hosts, to determine which one is malfunctioning.

If you look at the main pages for ping, you will see a number of other switches for ping to control things such as the source IP address for ping, interval, padding, and other potentially useful options. ping is also discussed in more detail in the next chapter, "Diagnostics."