Cry about...
MS-Windows Troubleshooting

---

General Network Connectivity Problems (e.g. cannot connect to remote computer)

---

Symptom:

Unable to connect to remote computer. General network connectivity problems.

Cause:

There are a number of things which can prevent two workstations from communicating with each other over the network. These include (and this is unlikely to be an exhaustive list):

• Poor or incorrect network protocol configuration
• Network hardware problems
• Software problems

The same can also cause problems even when superficially the network appears to be working.

Part of the problem in solving network connectivity problems is identifying what the underlying problem is or what the problems are.

Remedy:

The remedy to the problem depends on the root cause. The following should be regarded as a checklist of things to test:

1. Check that the workstation be ‘pinged’, i.e.:

   ping workstation

   If this produces the message ‘Bad IP address workstation.’ then this indicates a name resolution failure, in other words NT has been unable to look up the IP address for the workstation. If the (target) workstation is on the same local network then ask the administrator to check that DSN is working correctly. If it is on a remote network then the IP address will probably need to be explicitly specified in the local TNSNAMES file. Alternately try pinging by specifying explicitly the IP address of the workstation, i.e.:

   ping workstation-ip-address

   e.g.

   ping 192.168.44.1 (or whatever the ip address of the workstation is.)

   If ping produces a message of the form:

   Reply from ip-address: bytes=32 time<10ms TTL=128
Reply from ip-address: bytes=32 time<10ms TTL=128
Reply from ip-address: bytes=32 time<10ms TTL=128
Reply from ip-address: bytes=32 time<10ms TTL=128

   Then this indicates that there is network connectivity between the two workstations. Packets are being sent to the workstation and replies received. The time may vary. However, if it produces the message:

   Request timed out.
Request timed out.
Request timed out.
Request timed out.

   Then this indicates that there is no network connectivity between the two workstations. Things to check:

   • That the remote workstation is switched on.
   • That both workstations are (physically) plugged into the network.
   • That the hubs are switched on.
   • That the ip address that is being pinged (which ping echoes) is correct for the workstation. If it is not then this indicates either a DNS failure or an incorrect TNSNAMES entry.
   • That the remote workstation does not have a firewall that is preventing ping acknowledgements from being returned.
   • If both workstations are on a local network that their TCP subnet is the same. This can be checked using:

     ipconfig

     Do this on both workstations. For each network adapter this will show the following information:

     IP Address. . . . . . . . . : ip-addresss
Subnet Mask . . . . . . . . : subnet-mask
Default Gateway . . . . . . : gateway-ip (may be blank)

     For a local network the subnets should be the same. The ip-address logically and-ed with the subnet-mask should give the same result. If it does not then the workstations are on different subnets. Check the ip-addresses.

   • If the workstations are on different subnets then the packet will have been sent not directly to the workstation but via a gateway (and from there on to the workstation). To show the default gateway use:

     ipconfig

     To list all other possible gateways use the command:

     route print

     This lists other possible gateways that the workstation may use according to the ip address of the target. If the destination IP address does not match one of the network destinations listed then the default gateway will be used.

     If there is no default gateway the add the ip address of the gateway as the default. Otherwise check that the gateway is listed in the routing table. The ‘route’ command allows new entries to be added.

     Repeat the process (at both ends) but by pinging the gateway. This will establish whether there is basic communications between the workstation and its local gateway. If both sides can communicate with their respective gateways then the problem must lie with the link between the gateways. Consult your network administrator.

2. If the computers are on different networks try:

   tracert workstation

   This will show the route to the computer any may give a better indication of where on the route the problem lies.

3. Ping demonstrates that there is network connectivity between the two workstations. To check network reliability trying pinging with larger packets and for longer. Try each of the following:

   ping workstation -l 1024 -t
ping workstation -l 4096 -t
ping workstation -l 8192 -t

   The ‘-l’ parameter specifies the size of the message to send (the default is 32bytes, real applications will send much larger blocks of data). The ‘-t’ parameter specifies that it should continue pinging until you ‘control-C’ it. I would recommend trying each in turn and only breaking it after a complete screen full of responses. As the packet size increases the time will also increase. However even with 8192 byte packets there should be no ‘Request timed out’ messages. If any are seen then this indicates a hardware problem, either with the network hardware or with one of the adapters in either of the workstations.

   Typical response times I would expect for a set of sample packet sizes are as follows:

   Packet Size	100mbps LAN	10mbps LAN	100mbps to 10mbps LAN via single gateway
   -l 4096	time<10ms	<10ms	10ms
   -l 8192	time<10ms	10ms	10ms
   -l 16000	time<10ms	30ms	30ms
   -l 30000	time<10ms	50ms	50ms
   -l 60000	time=10ms	100ms	110ms

   Network topology will vary between sites (for instance the number of routers and switches that the network traffic request must navigate), so please regard these as ballpark/guideline figures. Any small variation between these figures and the figures are your site are probably not significant. The first ping message may show a higher time or even timeout, this is not significant provided it is only the first message.

   To check whether it is a network adapter on either of the workstations look in the NT (system) event log. This may indicate if the adapter is giving problems. It could also be the network cable, hub or particular hub port. If the problem affects one particular workstation then this is indicative of either a network card failure, bad network cable or network hub port failure. For example if there are problems between workstations ‘A’ and ‘B’, also between ‘A’ and ‘C’ but not between ‘B’ and ‘C’ then this clearly indicates that the problem is related to workstation ‘A’. Try a different port on the network hub, then a different network cable and then try a different network card.

4. If ping attempts fail the network appears to be totally unresponsive at one workstation (i.e. it cannot see anything on the network, even other workstations on the local network for which there are no network connectivity issues) then it is worth reinstalling the latest service pack. Some old dlls on the system can produce network related problems. It’s worth a try.
5. Enable ‘Black Hole Router detection’. Part of the underlying network protocol involves the network cards in both computers negotiating agreeing on the largest packet size that they can mutually manage. (For Ethernet this is typically 1550 bytes.) When communicating over a WAN it is possible that some of the routers or bridges along the route will not be able to handle packets as large as the network cards can manage. These should return a message indicating when a packet is too large and at the same time specify the maximum packet size they in turn can manage. Normal TCP-IP communication is self tuning in this way. However some (older?) routers or bridges fail to respond correctly and quietly drop the packet if it is too large. These are known as ‘black hole routers’. In NT black hole router detection is disabled by default. To turn it on requires adding (or modifying the following registry key):

   HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Services\ Tcpip\ Parameters\
EnabledPMTUBHDetect = 1

   If adding this registry entry then add it as a REG_DWORD.

Other than event log, registry and service pack references these notes are also applicable to Windows 9x.

---

These notes have been tested with Windows NT4 and W2K