Troubleshooting Other Connection Problems

In addition to ping, the other diagnostic utilities such as netstat and nbtstat can be used to find and resolve connection problems. Although this is not a complete list, these examples show how you might use these utilities to track down problems on the network.

To determine the cause of Error 53 when connecting to a server

1. If the computer is on the local subnet, confirm that the name is spelled correctly and that the target computer is running TCP/IP as well. If the computer is not on the local subnet, be sure that its name and IP address mapping are available in the LMHOSTS file or the WINS database.

   Error 53 is returned if name resolution fails for a particular computer name.

2. If all TCP/IP elements appear to be installed properly, use ping with the remote computer to be sure that its TCP/IP software is working.

To determine the cause of long connect times after adding to LMHOSTS

• Because this behavior can occur with a large LMHOSTS file with an entry at the end of the file, mark the entry in LMHOSTS as a preloaded entry by following the mapping with the #PRE tag. Then use the nbtstat -R command to update the local name cache immediately.

  – Or –

  Place the mapping higher in the LMHOSTS file.

  As discussed in Chapter 15, "Setting Up LMHOSTS," the LMHOSTS file is parsed sequentially to locate entries without the #PRE keyword. Therefore, you should place frequently used entries near the top of the file and place the #PRE entries near the bottom.

To determine the cause of connection problems when specifying a server name

• Use the nbtstat -n command to determine what name the server registered on the network.

  The output of this command lists several names that the computer has registered. A name resembling the computer's computer name should be present. If not, try one of the other unique names displayed by nbtstat.

  The nbtstat utility can also be used to display the cached entries for remote computers from either #PRE entries in LMHOSTS or recently resolved names. If the name the remote computers are using for the server is the same, and the other computers are on a remote subnet, be sure that they have the computer's mapping in their LMHOSTS files.

To determine why only IP addresses work for connections to foreign systems but not host names

1. Make sure that the appropriate HOSTS file and DNS setup have been configured for the computer by checking the host name resolution configuration using the Network icon in Control Panel and then choosing the DNS button in the TCP/IP Configuration dialog box.
2. If you are using a HOSTS file, make sure that the name of the remote computer is spelled the same and capitalized the same in the file and by the application using it.
3. If you are using DNS, be sure that the IP addresses of the DNS servers are correct and in the proper order. Use ping with the remote computer by typing both the host name and IP address to determine whether the host name is being resolved properly.

To determine why a TCP/IP connection to a remote computer is not working properly

• Use the netstat -a command to show the status of all activity on TCP and UDP ports on the local computer.

  The state of a good TCP connection is usually established with 0 bytes in the send and receive queues. If data is blocked in either queue or if the state is irregular, there is probably a problem with the connection. If not, you are probably experiencing network or application delay.