Article ID: 102908
Article Last Modified on 2/20/2007
APPLIES TO
- Microsoft Windows 2000 Server
- Microsoft Windows 2000 Advanced Server
- Microsoft Windows 2000 Professional Edition
- Microsoft Windows 2000 Datacenter Server
- Microsoft Windows NT Advanced Server 3.1
- Microsoft Windows NT Server 4.0 Standard Edition
- Microsoft Windows NT Workstation 3.1
- Microsoft Windows NT Workstation 4.0 Developer Edition
- Microsoft Windows NT Advanced Server 3.1
This article was previously published under Q102908
For a Microsoft Windows XP version of this article, see 314067.
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. 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 system?
A: Trying using PING on the local system by typing the IP loopback 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.
Q: How can I determine if the FTP Server service is installed correctly on a Windows system?
A: Try using FTP on the local system by typing the IP loopback 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 (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.
Q: What causes Error 53 when I'm connecting to a Windows NT, Windows for Workgroups, or Microsoft LAN Manager server?
A: Error 53 is returned when the specified computername cannot be 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.
Q: After I've added a new mapping to the LMHOSTS file, what can I do if it takes an unusually long time to connect to the server?
A: A large LMHOSTS file with an entry at the end of the file, possibly 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.
Q: What should I do if users are having difficulty connecting to a particular server, even when specifying the same name?
A: Use the NBTSTAT -N command to determine (authoritatively) what 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.
Q: What should I do when I cannot connect to foreign systems with hostnames using TELNET, FTP, and so on, but can only connect using IP addresses?
A: Using the Network icon in Control Panel, check the hostname 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.
Q: The banner displayed when I am using TELNET with a particular computer identifies a computer other than the one that I intended to connect to, even when I am specifying the correct IP address. How can this be?
A: Situations like this usually arise when two systems on the same 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.
Q: What should I do when a TCP/IP connection to a remote system appears to be hung?
A: The NETSTAT -a command shows the status of all activity on TCP and 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.
Q: What should I do when the TCP/IP configuration dialog box reports: "Your default gateway does not belong to one of the configured interfaces. Do you want to change it?"
A: This error indicates that the default gateway is not located on the 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.
Additional query words: wfw wfwg prodnt tshoot ntfaqipr
Keywords: kbnetwork KB102908
