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.
How can I determine whether TCP/IP is installed correctly on a
Trying using PING on the local system by typing the IP loopback
address of 127.0.0.1 at the command line:
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.
How can I determine if the FTP Server service is installed
correctly on a Windows system?
Try using FTP on the local system by typing the IP loopback
address at the command line:
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
What causes Error 53 when I'm connecting to a Windows NT, Windows
for Workgroups, or Microsoft LAN Manager server?
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.
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 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.
What should I do if users are having difficulty connecting to a
particular server, even when specifying the same name?
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
What should I do when I cannot connect to foreign systems with
hostnames using TELNET, FTP, and so on, but can only connect using
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.
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?
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.
What should I do when a TCP/IP connection to a remote system
appears to be hung?
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.
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?"
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 18.104.22.168 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