52
One such program is echoping. It is very similar to ping. It works by sending packets to one of several services that may be offered over TCP and UDP—ECHO, DISCARD, CHARGEN, and HTTP.
Particularly useful when ICMP messages are being blocked, echoping may work where ping fails.
If none of these services is available, echoping cannot be used. Unfortunately, ECHO and CHARGEN have been used in the Fraggle denial of service attacks. By sending the output from CHARGEN a
character-generation protocol to ECHO, the network can be flooded. Consequently, many operating systems are now shipped with these services disabled. Thus, the program may not be as useful as ping.
With Unix, these services are controlled by inetd and could be enabled if desired and if you have access to the destination machine. But these services have limited value, and you are probably better
off disabling them.
In this example, I have previously enabled ECHO on lnx1:
bsd1 echoping -v lnx1 This is echoping, version 2.2.0.
Trying to connect to internet address 205.153.61.177 to transmit 256 bytes... Connected...
Sent 256 bytes... 256 bytes read from server.
Checked Elapsed time: 0.004488 seconds
This provides basically the same information as ping. The -v option simply provides a few more details. The program defaults to TCP and ECHO. Command-line options allow UDP packet or the
other services to be selected.
When ping was first introduced in this chapter, we saw that www.microsoft.com could not be reached by ping. Nor can it be reached using echoping in its default mode. But, as a web server, port 80 should
be available. This is in fact the case:
bsd1 echoping -v -h ms.htm www.microsoft.com:80 This is echoping, version 2.2.0.
Trying to connect to internet address 207.46.130.14 port 80 to transmit 100 bytes...
Connected... Sent 100 bytes...
2830 bytes read from server. Elapsed time: 0.269319 seconds
Clearly, Microsoft is blocking ICMP packets. In this example, we could just as easily have turned to our web browser. Sometimes, however, this is not the case.
An obvious question is Why would you need such a tool? If you have been denied access to a network, should you be using such probes? On the other hand, if you are responsible for the security
of a network, you may want to test your configuration. What can users outside your network discover about your network? If this is the case, youll need these tools to test your network.
3.3.4.3 arping
53
Another interesting and useful variant of ping is arping. arping uses ARP requests and replies instead of ICMP packets. Here is an example:
bsd2 arping -v -c3 00:10:7b:66:f7:62 This box: Interface: ep0 IP: 172.16.2.236 MAC address: 00:60:97:06:22:22
ARPING 00:10:7b:66:f7:62 60 bytes from 172.16.2.1 00:10:7b:66:f7:62: icmp_seq=0
60 bytes from 172.16.2.1 00:10:7b:66:f7:62: icmp_seq=1 60 bytes from 172.16.2.1 00:10:7b:66:f7:62: icmp_seq=2
--- 00:10:7b:66:f7:62 statistics --- 3 packets transmitted, 3 packets received, 0 unanswered
2 packets transmitted, 2 packets received, 0 unanswered
In this case, Ive used the MAC address, but the IP address could also be used. The -v option is for verbose, while -c3 limits the run to three probes. Verbose doesnt really add a lot to the default output,
just the first line identifying the source. If you just want the packets sent, you can use the -q, or quiet, option.
This tool has several uses. First, it is a way to find which IP addresses are being used. It can also be used to work backward, i.e., to discover IP addresses given MAC addresses. For example, if you have
captured non-IP traffic e.g., IPX, etc. and you want to know the IP address for the traffics source, you can use arping with the MAC address. If you just want to check connectivity, arping is also a
useful tool. Since ARP packets wont be blocked, this should work even when ICMP packets are blocked. You could also use this tool to probe for ARP entries in a router. Of course, due to the nature
of ARP, there is not a lot that this tool can tell you about devices not on the local network.
3.3.4.4 Other programs
There are other programs that can be used to check connectivity. Two are described later in this book. nmap is described in
Chapter 6 , and hping is described in
Chapter 9 . Both are versatile tools that can
be used for many purposes. A number of ping variants and extended versions of ping are also available, both freely and
commercially. Some extend pings functionality to the point that the original functionality seems little more than an afterthought. Although only a few examples are described here, dont be fooled into
believing that these are all there are. A casual web search should turn up many, many more.
Finally, dont forget the obvious. If you are interested in checking only basic connectivity, you can always try programs like telnet or your web browser. While this is generally not a recommended
approach, each problem is different, and you should use whatever works. For a discussion of the problems with this approach, see
Using Applications to Test Connectivity .
Using Applications to Test Connectivity
One all-too-common way of testing a new installation is to see if networking applications are working. The cable is installed and connected, the TCPIP stack is configured, and then
a web browser is started to see if the connection is working. If you can hit a couple of web sites, then everything is alright and no further testing is needed.
This is understandably an extremely common way to test a connection. It can be particularly gratifying to see a web page loading on a computer you have just connected to your
54
network. But it is also an extremely poor way to test a connection. One problem is that the software stack you use to test the connection is designed to hide
problems from users. If a packet is lost, the stack will transparently have the lost packet resent without any indication to the user. You could have a connection that is losing 90 of
its packets. The problem would be immediately obvious when using ping. But with most applications, this would show up only as a slow response. Other problems include locally
cached information or the presence of proxy servers on the network.
Unfortunately, web browsers seem to be the program of choice for testing a connection. This, of course, is the worst possible choice. The webs slow response is an accepted fact of
life. What technician is going to blame a slow connection on his shoddy wiring when the alternative is to blame the slow connection on the Web? What technician would even
consider the possibility that a slow web response is caused by a cable being too close to a fluorescent light?
The only thing testing with an application will really tell you is whether a connection is totally down. If you want to know more than that, you will have to do real testing.
3.4 Microsoft Windows
The various versions of Windows include implementations of ping. With the Microsoft implementation, there are a number of superficial differences in syntax and somewhat less
functionality. Basically, however, it works pretty much as you might expect. The default is to send four packets, as shown in the two following examples. In the first, we successfully ping the host
www.cabletron.com:
C:\ping www.cabletron.com Pinging www.cabletron.com [204.164.189.90] with 32 bytes of data:
Reply from 204.164.189.90: bytes=32 time=100ms TTL=239 Reply from 204.164.189.90: bytes=32 time=100ms TTL=239
Reply from 204.164.189.90: bytes=32 time=110ms TTL=239 Reply from 204.164.189.90: bytes=32 time=90ms TTL=239
C:\
In the next example, we are unable to reach www.microsoft.com for reasons previously explained:
C:\ping www.microsoft.com Pinging microsoft.com [207.46.130.149] with 32 bytes of data:
Request timed out. Request timed out.
Request timed out. Request timed out.
Note that this is run in a DOS window. If you use ping without an argument, you will get a description of the basic syntax and a listing of the various options:
