The difficulty in troubleshooting TCP/IP connectivity problems on a Windows network stems from the sheer number of connections and services on a particular system. Identifying the status of the connections and which services are running can help you narrow down the search, but doing so takes time. However, an underused Windows command-line utility, NETSTAT, can shorten the time it takes to hunt down rogue connections by quickly providing information about client services and TCP/IP communications. Here is an explanation of how it works and how to interpret the information it displays.
NETSTAT utility basics
To use the NETSTAT utility in Windows NT or 2000, you must shell out to a command prompt; in Windows 9x or Me, use an MS-DOS prompt. To do its job, the NETSTAT utility requires parameters, which are described in Table A.
The syntax for the NETSTAT utility is NETSTAT [–a] [–e] [–n] [–s] [–p protocol] [–r] [interval], where you replace protocol with the specified protocol (either UDP or TCP) and replace interval with a specified interval.
|–a||Displays all connections and listening ports|
|–e||Displays Ethernet statistics|
|–n||Displays addresses and port numbers in numerical form instead of using friendly names|
|–s||Displays statistics categorized by protocol|
|–p protocol||Shows connections for the specified protocol, either TCP or UDP|
|–r||Displays the contents of the routing table|
|interval||Displays selected statistics, pausing interval seconds between each display; press [Ctrl]C to stop displaying statistics|
Using the NETSTAT utility to investigate TCP/IP connections
To investigate the status of all the current TCP/IP connections and identify which IP services are running on a particular system, use the NETSTAT utility’s base parameters, –a and –n. You can even combine the two parameters for a concise analysis of the of the current TCP/IP connections.
Figure A shows a sample output from the –a parameter.
As you can see from the results generated, this parameter displays all active TCP connections and available UDP ports using friendly names where possible.
Figure B shows a sample output from the –n parameter.
From this image, you can see that using the –n parameter displays only the TCP connections and uses numeric addresses instead of friendly names.
Figure C shows a sample of results from combining the two parameters.
This format provides you with the cleanest display, making it easier to read the information on the current TCP/IP connections.
Analyzing the results displayed by the NETSTAT utility
When you use the NETSTAT utility’s base parameters, –a and –n, four columns of statistics will be displayed. Next, I will explain how to interpret the statistics that appear under each column header.
Under the Proto column, you’ll find the name of the protocol being used by this particular connection. The protocol will be either TCP or UDP. You can use this information to verify that your protocol type is appropriate for the connection being investigated.
The IP address of the local computer and the port number being used for this particular connection appear in the Local Address column. The port number follows the colon. For example, in the ninth row in Figure C, the IP address of the local computer is 192.168.1.101, and the port number is 139.
When you use the –a parameter and a corresponding friendly name exists, the name will appear instead of the IP address or the port number. If the port exists but hasn’t been established, you'll see an asterisk in place of the port number.
The Foreign Address column contains the IP address of the remote computer and the port number being used for this particular connection. Again, if a corresponding friendly name exists and is found, it will appear instead of the IP address or the port number. If the port exists but hasn’t been established, an asterisk will be used in place of the port number.
To interpret the information in the State column, you need a basic understanding of how the three-way handshake communication system works for both initiating and closing a connection.
Initiating a connection:
- When a client system wants to make a connection with a server system, it sends a SYN message. (SYN stands for synchronize sequence numbers. It consists of the client’s unique initial sequence number [ISN] and the port number on the server to which the client wants to connect.)
- When the server receives a SYN message from a client, it requests a confirmation by replying with its own SYN message—its unique ISN along with the port number to which a connection request was made—and an acknowledgment (ACK), which consists of the client’s ISN plus one.
- The client then confirms the request by replying with an ACK, which consists of the server’s ISN plus one.
Closing a connection:
- When a client is finished sending data to the server, it sends a finish (FIN) message. At this point, the connection is half closed; the client is no longer sending data, but it can still receive data from the server.
- The server responds by sending an ACK, which consists of the client’s FIN plus one. The server then sends a FIN message.
- The client responds with its own ACK, which consists of the server’s FIN plus one. At this point, the server closes the connection.
Want to know more about three-way handshakes?
You can find detailed information on how this three-way handshake communication system works in RFC793 under the Functional Specification section.
The contents of the State column tell you the condition of the particular connection. These states represent the three-way handshake communication system that TCP uses. Table B lists the 10 possible states that can appear in this column. A connection that isn't functioning properly will list a condition that isn't appropriate for that particular type of connection.
|CLOSED||Indicates that the server has received an ACK signal from the client and the connection is closed|
|CLOSE_WAIT||Indicates that the server has received the first FIN signal from the client and the connection is in the process of being closed|
|ESTABLISHED||Indicates that the server received the SYN signal from the client and the session is established|
|FIN_WAIT_1||Indicates that the connection is still active but not currently being used|
|FIN_WAIT_2||Indicates that the client just received acknowledgment of the first FIN signal from the server|
|LAST_ACK||Indicates that the server is in the process of sending its own FIN signal|
|LISTENING||Indicates that the server is ready to accept a connection|
|SYN_RECEIVED||Indicates that the server just received a SYN signal from the client|
|SYN_SEND||Indicates that this particular connection is open and active|
|TIME_WAIT||Indicates that the client recognizes the connection as still active but not currently being used|
When you use the NETSTAT utility to investigate the status of all the current TCP/IP connections on a particular system, you’ll need to be able to identify the port numbers and tell which services correspond to them. You can find a detailed list of TCP and UDP port assignments on Microsoft’s Windows 2000 Web site.
A command-line alternative
If the information provided by the NETSTAT utility is just what you need for your troubleshooting expeditions, but you hate working from the command line, you may want to investigate X-NetStat Professional from Fresh Software. This terrific utility runs from a GUI and provides you with the same information provided by the NETSTAT utility and more. You can download X-NetStat Professional free for 30 days. After that, you must either uninstall the program or register your copy for $30. However, if you are a registered owner of the X-NetStat Standard edition, you can upgrade for only $15. Look for an upcoming TechProGuild article on this product.
The NETSTAT utility is an excellent tool to interpret TCP/IP connections on your network. Using the NETSTAT utilities base parameters –a and -n, you can explore the status of current TCP/IP connections and discover what IP services are running on a particular system. By providing information about the current state of client services and TCP/IP communications, this utility can help you shorten the time it takes to troubleshoot problem TCP/IP connections.
Greg Shultz is a freelance Technical Writer. Previously, he has worked as Documentation Specialist in the software industry, a Technical Support Specialist in educational industry, and a Technical Journalist in the computer publishing industry.