How to Troubleshoot TCP/IP Connectivity with Windows NT

• Microsoft Windows NT operating system version 3.1
• Microsoft Windows NT Advanced Server version 3.1
• Microsoft Windows NT Server version 4.0
• Microsoft Windows NT Workstation version 4.0

SUMMARY

The ARP, PING, FTP, NETSTAT, and NBTSTAT utilities can provide useful information when you are trying to determine the cause of TCP/IP networking problems with Windows NT. Below is a list of possible TCP/IP symptoms with recommendations for using these utilities to diagnose the problems. Although this is not a complete list, these are examples of how you might use these utilities to track down problems on the network.

MORE INFORMATION

Q: How can I determine whether TCP/IP is installed correctly on a

   Windows NT system?

   address of 127.0.0.1 at the command line:

      ping 127.0.0.1

   The system should respond immediately. If PING is not found, or the
   command fails, check the event log with Event Viewer and look for
   problems reported by Setup or the TCP/IP service. You should also
   attempt to use PING with the IP addresses of your local
   interface(s) to determine whether you configured IP properly.
   Successful use of PING indicates that the IP layer on the target
   system is probably functional.

   correctly on a Windows NT system?

   address at the command line:

      ftp 127.0.0.1

   The interaction with the server locally is identical to the
   interaction expected for other Windows NT (and most UNIX) clients.
   This command can also be used to determine whether the directories,
   permissions, and so on of the FTP Server service are configured
   properly.

   for Workgroups, or Microsoft LAN Manager server?

   resolved. If the computer is on the local subnet, confirm that the
   name is spelled correctly and that the target system is running
   TCP/IP as well. If the computer is not on the local subnet, make
   sure that its name and IP address mapping are available in the
   LMHOSTS file. If everything appears to be installed properly, try
   using PING with the remote system to make sure that its TCP/IP
   software is functional.

   if it takes an unusually long time to connect to the server?

   following some #INCLUDEs, could cause this behavior. You can do two
   things to speed up the connect time: either mark the entry as a
   preloaded entry by following the mapping with the #PRE tag and use
   the NBTSTAT -R command to update the local name cache immediately,
   or place the mapping higher in the LMHOSTS file.

   The LMHOSTS file is parsed sequentially to locate non #PREloaded
   entries. Therefore, you should place frequently used entries near
   the top of the file and the #PRE entries near the bottom.

   particular server, even when specifying the same name?

   the server registered on the network. The output of this command
   lists several names that the system has registered using NetBIOS
   over TCP/IP. One resembling the system's computername should be
   present. If not, try one of the other unique names displayed. The
   NBTSTAT command can also display the cached entries for remote
   systems either #PREloaded from LMHOSTS or recently resolved names
   due to current network activity. If the name the remote users are
   using is the same, and the other systems are on a remote subnet,
   make sure that they have the system's mapping in their LMHOSTS
   file.

   hostnames using TELNET, FTP, and so on, but can only connect using
   IP addresses?

   resolution configuration (found under the TCP/IP Connectivity
   option) to be sure that the appropriate HOSTS and DNS setup has
   been configured for the system. If you are using the HOSTS file,
   make sure the remote system is spelled the same way in the file as
   it is being used by the application. If you are using DNS, make
   sure the IP addresses of the DNS servers are correct and in the
   proper order. To determine whether the hostname is being resolved
   properly, try using PING with the remote system by typing both the
   hostname and IP address.

   computer identifies a computer other than the one that I intended
   to connect to, even when I'm specifying the correct IP address.
   How can this be?

   network are configured (mistakenly) with the same IP address. The
   Ethernet and IP address mapping is done by the address resolution
   protocol (ARP) module, which believes the first response it
   receives. So the impostor computer's reply sometimes comes back
   before the intended computer's reply. These problems are difficult
   to isolate and track down. The command ARP -g displays the mappings
   in the ARP cache. If you know the Ethernet address for the intended
   remote system, you can easily determine if the two match. If not,
   try using ARP D to delete the entry, then PING the same address
   (forcing a new ARP mapping) and check the Ethernet address in the
   cache again using ARP -g. Chances are that if both systems are on
   the same network, you will eventually get a different response. If
   not, you may need to filter the traffic from the impostor host to
   determine the owner or location of the system.

   appears to be hung?

   UDP ports on the local system. 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.

   "Your default gateway does not belong to one of the configured
   interfaces. Do you want to change it?"

   same logical network as any of the installed interface(s) on the
   system. This is determined by comparing the net ID portion of the
   default gateway (by computing a bitwise AND operation between the
   subnet mask and the default gateway) and the net ID(s) of any of
   the installed interfaces. For example, a system with a single
   interface configured with an IP address of 102.54.0.1 and a subnet
   mask of 255.255.0.0 would require that the default gateway be of
   the form 102.54.a.b because the net ID portion of the IP interface
   is 102.54.