Using ping and tracert to Check Connectivity
Using ping and tracert to Check ConnectivityTwo of the most basic commands that can be used to test connectivity on a TCP/IP network are the ping command and the tracert command. In this section we'll look at how these commands work and the kind of troubleshooting information you can gain from their use. The ping CommandThe ping command is a good place to start your troubleshooting efforts. The name of this command might not make a whole lot of sense at first glance. This utility is used to test connectivity between two systems on the network. ping uses the ICMP protocol (which, you'll remember, uses UDP packets for transport) to exchange packets with the remote system. This utility was originally developed by Mike Muuss and operates in a simple manner. It uses the ICMP protocol to send UDP messages to an address (ECHO REQUEST) and waits to hear for a reply (ECHO REPLY). The remote system sends the reply packets back to their source, and the round-trip is determined. Thus, ping is used to "grope" around trying to find out whether it can communicate with another system on the network. You also can think of ping as a sonar type of mechanism.
Figure 27.1 shows the layout of the ICMP ECHO REQUEST and ECHO REPLY packets. If the message type is an ECHO REQUEST, the first field of the ICMP (message type) packet will have a value of 8. If the message type is an ECHO REPLY, this field will contain a zero. Figure 27.1. Layout of the ICMP ECHO REQUEST and ECHO REPLY packets. Using ping on Unix and Linux SystemsThe way that ping functions is quite simple. The sequence number field is first set to zero, and then incremented for each packet sent. On most Unix and Linux implementations, the identification field is set to the process ID of the process sending the ping ECHO REQUEST message. This can vary with other operating systems, but the identifier is important and is used to uniquely identify the returned packets in case more than one user on a machine is using the utility at the same time. When the receiving computer gets the ECHO REQUEST message, it sends back a reply containing the identifier and the sequence number. In this way the receiving machine can tell whether all packets are returned and also, more important, tell you if packets are being dropped or returned out of order. These conditions can indicate problems on the network. Another possibility is that the remote system is working at a high capacity and cannot respond to all the ECHO REQUEST messages in a timely manner. The ping utility tells you how long (in milliseconds) the round-trip took, and it tells you when packets do not make it back successfully. To determine the round-trip time, the utility stores the time that it sends the initial request packet in the optional data portion of the packet and compares it to the current time when the reply packet is received. The basic program also prints a Time to Live (TTL) value, which is typically decremented by at least one second for each host or router through which the packet passes. Occasionally you will notice that the round-trip time value declines for subsequent ping requests. This is because the destination machine (or the gateway router) isn't currently in the local ARP table, and it takes a few milliseconds for arp to determine the hardware address for sending out the first packet. If you ping by using a hostname instead of a TCP/IP address, it might take a few seconds for the ping utility to contact a DNS server and resolve the hostname to the IP address. When you're using ping, it's best to first use it to ping the local interface, or the loopback address (127.0.0.1, or 120.0.0.1 on some older systems). The loopback address is used in TCP/IP stacks to enable you to test whether the local stack is functioning correctly. This is a reserved IP address that cannot be used on the Internet. If you can't ping the local system's own IP address, you might have a configuration problem. If you can't ping the loopback address, you might have a problem with the TCP/IP stack or perhaps the network adapter. In RFC 2151, "A Primer on Internet and TCP/IP Tools and Utilities," the basic ping syntax is defined as follows: ping [-q] [-v] [-R] [-c Count] [-i Wait] [-s PacketSize] Host
An older syntax for ping that you might find is ping [-s] {IP_address|hostname} [PacketSize] [Count] When using the -s option, the ping command will send a message to the target every second. This can be helpful when you are monitoring an intermittent problem and want to be able to watch in real time whether a connection can be made. The syntax for ping can vary depending on the operating system, and even among different variants of Unix. However, its basic use is simply ping hostname or ping address. The syntax for a Linux ping follows: ping [-R] [-c number] [-d] [-I seconds] host The options include the following:
Using ping on Windows SystemsThe ping command has a much different syntax when used with the Windows operating systems (both servers and clients): ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS] [-r count] [-s count] [[-j host-list] | [-k host-list] [-w timeout] destination-list The options include the following:
As you can see, the syntax can vary widely between implementations, as can the usefulness of ping as a diagnostic tool. Following is an example of a simple use of the ping command: G:\>ping www.activewebhosting.com Pinging www.activewebhosting.com [24.120.30.50] with 32 bytes of data: Reply from 24.120.30.50: bytes=32 time=97ms TTL=105 Reply from 24.120.30.50: bytes=32 time=95ms TTL=105 Reply from 24.120.30.50: bytes=32 time=90ms TTL=105 Reply from 24.120.30.50: bytes=32 time=89ms TTL=105 Ping statistics for 24.120.30.50: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 89ms, Maximum = 97ms, Average = 92ms In this example, the computer is responding well. There was 0% packet loss in the transmissions, and the reply time was about 100 milliseconds. The size of the packet sent was 32 bytes. This simple usage of the ping command can tell you right away if there is a problem between two nodes on the network. It might be a broken cable, possibly a router configuration issue, or some other problem. But if you start with ping you'll find out right away whether there is an IP pathway between the two network nodes. If there is, you can begin to use other tools to explore why certain applications are not functioning. Note An inability to ping a remote node is not a guarantee that the node is disconnected physically from the network. In other words, you cannot simply assume that a ping failure indicates a wiring problem. It might be that an intermediary device, such as a switch, router, or gateway, is malfunctioning. This is one of the reasons you need to keep a detailed map of your network. When you have to troubleshoot you can check not just the end nodes, but also every device and cable along the path between them. Troubleshooting a Network Connection with the ping CommandFor basic connectivity troubleshooting, use the following steps:
As you can see from these steps, it is possible to use ping to help track down various problems that can occur, from simple connectivity to name resolution. Using ping as your first step can help point you in the right direction should other tools need to be used to continue the troubleshooting effort. For example, if you can ping the local broadcast domain members, and if you can ping the default gateway, the next step is to attempt to ping hosts outside your network, perhaps on the Internet. Note that the network administrator may disable this functionality if your company institutes a good firewall security policy. Many times the administrator for the firewall will prevent outgoing ICMP ECHO REPLY messages to keep intruders from outside the network from finding out information about computers protected by the firewall. For more information about allowing the ping utility to work through firewalls, see Chapter 45, "Firewalls." Note The ping utility serves an important function in troubleshooting TCP/IP network connectivity. However, the Ping of Death, which you've probably heard about, does not. This attack method uses a program that creates ICMP packets that are larger in size than is allowed. If the software on the receiving end is not patched, or is a new version, it might accept this larger-than-life packet, causing part of the program memory to be overwritten as the data is stored in the allocated buffer and, then, beyond. For more information about allowing the use of ping in a secure environment, see Chapter 44, "Security Issues for Wide Area Networks." The traceroute CommandIf you find that you cannot successfully ping a host that lies past your default gateway router, try using the TRaceroute (tracert for some operating systems, such as Windows) command. This command enables you to see every host that a packet passes through to get to the destination. Eventually you will find that the traceroute program cannot get past one of the routers in the path, and it is from there you should start investigating the problem. You can use this information to locate a troublesome router or other device along the network path. If you've established the fact that you can't get here from there, or that the response time is bad when using ping, try using the tracert command to determine the path that is being taken from your system to the target system. This diagnostic command is similar to ping in that it uses ICMP messages to try to locate each device through which a packet passes to reach its destination. This can provide useful information if you are not sure about the route being taken when you are trying to diagnose a sluggish response from ping. It also can help you find where along the network path the network is failing by showing each hop up until it fails if you can't get to the target system. For most Unix and Linux operating systems, the command to trace a route through the network is TRaceroute. From Windows 98 to Windows 2003, a version of this command is called tracert. No matter what the actual command name, this utility can determine each route through the network by setting the TTL (Time to Live) value in the packet, hoping to receive an ICMP TIME_EXCEEDED message from each hop the data packet takes on its path. Remember that the TTL value is the allowable number of hops a packet can take before it is discarded by IP. Thus, by setting this value, starting with one and incrementing by one for each pass, TRaceroute (or tracert) can get the TIME_EXCEEDED ICMP message from each router or other device through which the packet must pass. For each attempt, three packets are sent to average the time that it takes to get to that point in the network. The basic function of this utility appears in Figure 27.2. Figure 27.2. The tracert utility manipulates the TTL value to discover host systems along a particular route. In this figure, you can see that Computer A generates a series of ICMP ECHO REQUEST messages and sends them to Computer D. When the first packet is sent out, the TTL value is set to 1. It is decremented to zero at the first router, and an ICMP TIME EXCEEDED ICMP message is sent back to Computer A. Computer A then sends out another ICMP ECHO REQUEST packet, but this time sets the TTL value to 2. Thus, the first router passes the packet to the next router after decrementing the TTL value from 2 to 1. The second router looks at the TTL value of 1 and decrements it to zero, and once again an ICMP TIME EXCEEDED message is sent back to Computer A. As you can see, intermediate routers drop packets when the TTL value expires. An ICMP TIME_EXCEEDED message is sent back to Host A, until the TTL value has been set to a value sufficient to reach the destination Computer D. Thus, Computer A can determine the number of hops it took to reach Computer D, assuming that it is successful in getting there. The original traceroute utility sets the port in the UDP header to an "unreachable" port. Thus, when the TTL value is finally incremented enough so that the ICMP packet actually reaches the target system, it will return the ICMP DESTINATION UNREACHABLE message, as you can see in Figure 27.2. If the last hop you see in the traceroute output is the destination, the program has displayed all the hops between your system and the destination system. This can vary depending on the implementation of the utility. If the last hop that is returned by this command is not the target system, you should begin investigating the system that does show up as the last hop. Note Various implementations of the traceroute utility might function differently than the method just described here. Some use the function of the Record-Route option in IP to attempt to trace the route. However, because the amount of space to record routes is limited, and because the Internet is much larger than it was a few years ago, the UDP method that manipulates the TTL value is probably a more reliable way to implement this utility. The basic syntax for the traceroute command as given in RFC 2151 is traceroute [-m #] [-q #] [-w #] [-p #] {IP_address|host_name}
The syntax for using tracert in Windows NT/2000/XP and Windows 2003 Servers is tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name The more useful options include the following:
Of course, target name is the host computer that you are executing the tracert command for. The following is an example of the output from executing the Windows version of tracert: D:> tracert www.bellsouth.net Tracing route to www.bellsouth.net [205.152.0.46] over a maximum of 30 hops: 1 231 ms 200 ms 220 ms envlnjewsap02.bellatlantic.net. As you can see, you can gain a lot of information about how your network functions by using this command. The three columns show how long it took each of the three attempts to reach the particular node for that hop. An asterisk character that is displayed in any of these time columns indicates that the ICMP packet was not returned. The hostname and address are displayed by default. If the command fails at any point, you can start tracing the network fault at the last successful hop to determine where the fault lies. If you are using a Linux system, the following syntax may prove a useful reference. Because this is a Linux system, the command is not tracert, but instead is traceroute. traceroute [ -dFInrvx ] [ -f first_ttl ] [ -g gateway ] [ -i iface ] [ -m max_ttl ] [ -p port ] [ -q nqueries ] [ -s src_addr ] [ -t tos ] [ -w waittime ] [ -z pausemsecs ] host [ packetlen ] Options for the preceding commands are listed here:
If you have a map of your network, you can check to determine whether the best path is being followed when using the traceroute utilitymaybe a primary router is not up and running, and a backup path with a lower bandwidth is sending the packet on a different route through the network. If you use this command on a regular basis and keep an output of the information you see, you can learn to notice when a particular router used by your ISP (or possibly in your own network) is having problems. By using both ping and tracert, you can usually discover problem areas in your network and then plan steps to remedy the problem. If the problem lies outside your network, that is, with your ISP or some other router on the Internet, resolving the situation can be more problematic. However, for troubleshooting the internal corporate network, these commands should prove very useful for basic configuration and connectivity problems. The netstat and route CommandsOn Unix, Linux, and Windows systems, the netstat command is used to obtain statistics about the TCP/IP protocols that are in use on the computer. This command is most useful when you are trying to debug network problems. The route command is also useful because it can be used to view or manipulate the routing table on a computer. Using the netstat Command on Windows Operating SystemsThe syntax for netstat for Windows NT/2000/XP and Windows 2000/2003 Servers is netstat [-a] [-e] [-n] [-s] [-p protocol] [-r] [interval]
Windows XP and Windows Server 2003 add the following switches:
You can investigate a lot about the protocols operating on your system by using the netstat command, as you can see from the preceding syntax options. For example, the command netstat -r displays the routing table that is maintained on the current host. (Note that you can also use the command route print to display the routing table information. See Chapter 33 for more information about using the route command and its command-line options.) Following is an example of the routing table as shown using netstat -r and an explanation of the data that is shown using the Windows 2003 Server version of this command: IPv4 Route Table =========================================================================== Interface List 0x1 ........................... MS TCP Loopback interface 0x10003 ..00 04 5a 42 53 99 ..LNE100TX Fast Ethernet Adapter(LNE100TX v4) =========================================================================== =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.201 20 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.1.0 255.255.255.0 192.168.1.201 192.168.1.201 20 192.168.1.201 255.255.255.255 127.0.0.1 127.0.0.1 20 192.168.1.255 255.255.255.255 192.168.1.201 192.168.1.201 20 224.0.0.0 240.0.0.0 192.168.1.201 192.168.1.201 20 255.255.255.255 255.255.255.255 192.168.1.201 192.168.1.201 1 Default Gateway: 192.168.1.1 =========================================================================== Persistent Routes: None In this listing you can see the basic routing table used by this computer when you issue this command. If you become familiar with what the routing table should look like, this command might help you focus troubleshooting efforts and quickly spot a problem due to an incorrect routing table entry. Another important thing to remember is that there are many virus programs that manipulate the local host's routing table. On servers, check this table often. Note The o option used by the Windows XP and Windows Server 2003 version of netstat is also available on many Linux computers. Each line in this display starts with a destination address. When a decision is being made as to where to send a packet, this table is consulted to see whether one of these destination addresses matches the destination address of the packet in question. In the first line, the address of 0.0.0.0 might not seem to make sense. This is the entry, or the default gateway. That is, if a packet cannot be routed to its destination using any of the remaining entries in the route table, it will be sent to this address. The second column shows the netmask for this route entry. Like a subnet mask, this mask is used to mask out portions of the destination address when a routing decision is to be made. The netmask is converted to binary. When the decision is being made as to whether a packet matches the destination address, the portions of the destination address that are in the same position as a 1 must match the packet's destination address exactly. A netmask of 255.255.255.255 is a string of 32 ones in binary. This is used for a host address, and the packet must match the address exactly to be routed by this entry. The next column shows the gateway. Packets that match this entry will be sent to this address. The next columnInterfaceis the address of the network card or PPP adapter that the packet will be sent through. The last columnMetricshows the number of hops the packet will take to reach its final destination. The output for the Windows 2000/Server 2003 command is similar, but presented in a different format: C:\>netstat -r Route Table =========================================================================== Interface List 0x1 ........................... MS TCP Loopback interface 0x2 ...00 08 c7 ba 23 7f ...... Compaq Ethernet/FastEthernet or Gigabit NIC =========================================================================== =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 140.176.187.254 140.176.187.185 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 140.176.187.0 255.255.255.0 140.176.187.185 140.176.187.185 1 140.176.187.185 255.255.255.255 127.0.0.1 127.0.0.1 1 140.176.255.255 255.255.255.255 140.176.187.185 140.176.187.185 1 224.0.0.0 224.0.0.0 140.176.187.185 140.176.187.185 1 255.255.255.255 255.255.255.255 140.176.187.185 140.176.187.185 1 Default Gateway: 140.176.187.254 =========================================================================== Persistent Routes: None Other uses for the netstat command include showing the current state of TCP/IP ports and sockets (netstat -a) or showing the ARP table (use netstat -p on Unix or the arp command on Windows NT). To see statistics about the specific protocolsUDP, ICMP, TCP, or IPuse the netstat -s command. This is especially helpful when you are trying to diagnose connectivity problems that are intermittent or might be due to network congestion. The output is quite lengthy, so you might want to pipe the results to a text file (netstat -s > stats.txt). What follows is an example of the data you can obtain by using the -s option with this command on a Windows NT or Windows 2000/XP or Windows 2003 Server system: netstat s IP Statistics Packets Received = 19942 Received Header Errors = 0 Received Address Errors = 2 Datagrams Forwarded = 0 Unknown Protocols Received = 0 Received Packets Discarded = 0 Received Packets Delivered = 19942 Output Requests = 19682 Routing Discards = 0 Discarded Output Packets = 0 Output Packet No Route = 0 Reassembly Required = 0 Reassembly Successful = 0 Reassembly Failures = 0 Datagrams Successfully Fragmented = 0 Datagrams Failing Fragmentation = 0 Fragments Created = 0 ICMP Statistics Received Sent Messages 341 257 Errors 0 0 Destination Unreachable 30 16 Time Exceeded 142 0 Parameter Problems 0 0 Source Quenchs 0 0 Redirects 91 0 Echos 34 189 Echo Replies 44 34 Timestamps 0 0 Timestamp Replies 0 0 Address Masks 0 0 Address Mask Replies 0 0 TCP Statistics Active Opens = 454 Passive Opens = 0 Failed Connection Attempts = 4 Reset Connections = 33 Current Connections = 0 Segments Received = 6399 Segments Sent = 6359 Segments Retransmitted = 14 UDP Statistics Datagrams Received = 13184 No Ports = 325 Receive Errors = 0 Datagrams Sent = 13048 Again, the valuable information you get using this command can be very handy when troubleshooting networking problems. For example, you can check to see whether the number of errors or dropped packets is excessive when compared to your ordinary operating environment. To understand and make good use of this type of information, you should be familiar with the protocols that are displayed, such as IP and UDP. For more information about these protocols, see Chapter 24. To determine which protocols and port numbers are currently being used to create a connection on a system running Windows XP or Windows Server 2003, you can use netstat o, as in the following example: Active Connections Proto Local Address Foreign Address State PID TCP tiger-athlon:1032 localhost:1035 ESTABLISHED 556 TCP tiger-athlon:1032 localhost:1036 ESTABLISHED 556 TCP tiger-athlon:1032 localhost:1037 ESTABLISHED 556 TCP tiger-athlon:1035 localhost:1032 ESTABLISHED 556 TCP tiger-athlon:1036 localhost:1032 ESTABLISHED 556 TCP tiger-athlon:1037 localhost:1032 ESTABLISHED 556 To determine what program was used to create a connection when you use netstat o, you must configure Windows Task Manager to list the PID on the Processes tab. To do this, follow these steps:
If you prefer not to modify the default appearance of Task Manager, you can use the netstat b command to display the same type of information. However, the program used to create the connection is listed in brackets on the line following the PID. See this example: Active Connections Proto Local Address Foreign Address State PID TCP tiger-athlon:1032 localhost:1035 ESTABLISHED 556 [cli.exe] TCP tiger-athlon:1032 localhost:1036 ESTABLISHED 556 [cli.exe] TCP tiger-athlon:1032 localhost:1037 ESTABLISHED 556 [cli.exe] TCP tiger-athlon:1035 localhost:1032 ESTABLISHED 556 [cli.exe] TCP tiger-athlon:1036 localhost:1032 ESTABLISHED 556 [cli.exe] TCP tiger-athlon:1037 localhost:1032 ESTABLISHED 556 [cli.exe] TCP tiger-athlon:netbios-ssn 192.16.0.101:1873 ESTABLISHED 4 [System] Using the netstat Command on Unix or Linux SystemsThe syntax for the netstat command varies depending on which Unix or Linux implementation you are using; however, you will see similar information, and it will be mostly the formatting that changes. For example, the syntax for netstat for the FreeBSD Unix operating system is netstat [-AaLln] [-f address_family] [-M core] [-N system] netstat [-bdghilmnrs] [-f address_family] [-M core] [-N system] netstat [-bdn] [-I interface] [-M core] [-N system] [-w wait] netstat [-p protocol] [-M core] [-N system] netstat [-p protocol] [-i] [-I Interface] netstat [-s] [-f address_family] [-i] [-I Interface] where
For Linux the capabilities of this command grow to encompass a larger number of functions. Most of the command options previously listed will work in the same manner for Linux. To find out about more complex commands that can be used with this utility to troubleshoot network problems, see the man page man netstat. The arp CommandIP addresses and hostnames are used for the convenience of humans so that we can configure and manage a network in an orderly manner. At the lowest level, however, network cards use the hardware MAC address when they talk to each other. Remember that a computer finds out the hardware address of another computer on the local segment by using the Address Resolution Protocol (ARP). Just as a host computer keeps a table of routing information, it also keeps a cache of MAC-to-IP address translations known as the ARP table. The arp command enables you to view the ARP table and to add or delete entries within it. Again, the syntax varies among different systems. To show the differences you might encounter, let's look at the Windows 2000/XP and Windows 2003 Servers and then Linux versions of this command. For Windows 2000/XP and Windows 2003 Servers the syntax is ARP -s inet_addr eth_addr [if_addr] ARP -d inet_addr [if_addr] ARP -a [inet_addr] [-N if_addr]
For example, to add an address pair to the ARP table, you might use this: arp -s 192.123.111.2 08-00-2b-34-c1-01 For Linux systems the syntax is arp [-evn] [-H type] [i if] a [hostname] arp [-v] [-i if] -d hostname [pub] arp [-v] [-H type] [-i if] s hostname hw_addr [temp] arp [-v] [-H type] [-i if] s hostname hw_addr [netmask nm] pub arp [-v] [-H type] [-i if] Ds hostname ifa [netmask nm] pub arp [-vnD] [-H type] [i if] f [filename] where the command-line options are
As you can see, the arp command can be quite powerful. It should be used carefully when adding or deleting entries in the ARP table. However, for display purposes it can be easily used to determine problems of resolving hardware addresses on the local subnet or network segment. The tcpdump UtilityIf you are extremely knowledgeable about TCP/IP and are capable of understanding the bits and bytes of IP frames, you can use the tcpdump utility to capture header information from packets as they pass through the network. Because there can be a potential security problem with being able to view this information, it is not a utility that the ordinary Unix or Linux user can use. It is generally restricted to the root user or must be installed with setuid to root. Note When a file has "setuid to root bit" enabled, it means that the program will run with the privileges of the owner of the file, and not the privileges of the user who is running the program. In Unix or Linux systems, this feature allows the administrator to let users execute programs that perform specific tasks that require more privileges than the user has. However, the user is able to use the privileges only to run the program to accomplish a specific task. The user does not inherit the rights or privileges of the program after running it. Because the tcpdump utility can be used to examine network packets (and thus "snoop" on network traffic), it must run with the privileges granted to the root (or superuser) account. Many command-line parameters are associated with this utility, and you can create complex expressions that are used to evaluate which packets to intercept. You can also supply no selection criteria, and all packets will be dumped. Some of the more useful options for the tcpdump command are listed here:
There are additional advanced options, but the preceding options are the basic ones. The selection expression criteria can be quite complex, and you should consult the extensive man pages for tcpdump to get the full listing of other options, expressions, and examples. The scope of the capabilities of this program is beyond this book. A couple of simple uses follow: tcpdump host hercules This command shows packets that are going to or coming from the system named hercules. tcpdump ip host venus and not hercules This command shows packets going to or coming from the system named venus, unless they are coming from or going to hercules. The output displayed by this command depends on the protocol of the packet that is intercepted. You can download the most recent version and patches for this utility at www.tcpdump.org/. In addition, you can sign up for mailing lists that relate to this utility. Join the first list by sending an email message to the address tcpdumpannounce@tcpdump.org. This mailing list is used for announcements about the utility. The second mailing list is used for both announcements and discussions concerning the code of tcpdump. To subscribe to this mailing list, send an email to tcpdumpworkers@tcpdump.org. The source code for this program is also available for compilation on many different Unix and Linux platforms. Although it's not a tool for a novice, tcpdump can be used by a skilled administrator to diagnose network problems. This section has given you only a brief overview of the capabilities of this simple network capture utility. After installing the software, be sure to review any readme files for up-to-date information. The WinDump UtilityThe tcpdump utility has been ported to the Windows environment and is known as WinDump. Like the tcpdump program, this program was developed by the Network Research Group of the Information and Computing Sciences Division of the Lawrence Berkeley National Laboratory. More recent versions and patches for the utility are maintained at http://www.winpcap.org/windump/. By using WinDump, you can gain a lot of information by examining network packets to troubleshoot network problems. The interface, however, is different than the command-line version of tcpdump. The WinDump utility, like tcpdump, is covered under a Berkeley-style license. Note A Berkeley-style license means that you can share software with others as long as you include a copy of the license. You cannot use the code to create commercial products to sell, however. To use WinDump, you must first download and install the WinPcap Windows Packet Capture Library, available from http://www.winpcap.org/install/default.htm. The current version works with Windows 9x/Me/NT 4/2000/XP/2003 and even Windows Vista. To make WinDump usable from any location on your system, download it into your Windows folder (C:\Windows or C:\WinNT on most systems). After you install WinPcap, run WinDump (WinDump.exe) from the command line. Most of the command syntax for WinDump is similar to that of the tcpdump utility; consult the syntax listed earlier in this chapter for more help or go to the WinDump manual page at http://www.winpcap.org/windump/docs/manual.htm. One of the most useful additions to WinDump's syntax, compared to tcpdump's, is the D command switch. This lists the network adapters supported by WinDump by number and provides a description. Use the number along with the i switch to specify to which adapter to listen. Here's an example of the output from windump D: 1.\Device\NPF_GenericDialupAdapter (Generic dialup adapter) 2.\Device\NPF_{A3C21A7A-2C4D-4132-9BA8-588415B4EE47} (NVIDIA nForce MCP Networki ng Adapter Driver) To listen to network traffic on the integrated nForce network adapter (network device 2), use the command windump i2. Tip Both tcpdump and WinDump use both lowercase and uppercase command switches. Be sure to specify the correct case in your tcpdump or WinDump command, or you will get a syntax error or unexpected output. Again, remember that examining network packets is not a job for a novice. You should first have a good understanding of the frame types seen on your network and a good understanding of the types of datagrams sent by applications and services you use. Some of the standard packets you should familiarize yourself with include DNS, ICMP, and TCP session setup and close. Depending on the services your network uses, you can quickly become familiar with the type of expected network traffic and then use this tool to look for exceptions when troubleshooting. |
[192.168.125.189] 2 261 ms 160 ms 160 ms 192.168.125.158 3 180 ms 200 ms 181 ms 206.125.199.71 4 181 ms 160 ms 180 ms Hssi4-1-0.border2.teb1.IConNet.NET. 
EAN: 2147483647
Pages: 411