Troubleshooting Basic TCP/IP Problems

Date Launched: Jul 05, 2005 Last Updated: Jul 05, 2005 Section: Author: Over the last several years, TCP/IP has gone from being the protocol that only geeks use, to a universal protocol that everyone uses, thanks to the widespread use of the Internet. TCP/IP has been around for decades and is a solid, reliable, mature protocol. Most of the time when there is a TCP/IP related problem, the problem is related to the way that one or more of the hosts on the network are configured. In this article, I will walk you through the process of troubleshooting some common TCP/IP issues.

<img>

Step 1: Check the Configuration

The first step in the troubleshooting process is to check the TCP/IP configuration. The easiest way to do this is to open a Command Prompt window and enter the IPCONFIG /ALL command. Windows will then display the configuration results. Its important to point out that some computers have multiple network interface cards, and Windows may also treat a Firewire port as a network adapter. You must therefore be careful to make sure that you are looking at the configuration thats bound to the interface thats actually connected to the network. If the configuration appears to be blank, then the interface has not been assigned an IP address. IP addresses can be assigned manually, or via a DHCP server. If your organization uses a DHCP server to assign IP addresses, then try entering the following series of commands to see if the machine is able to obtain an IP address: IPCONFIG /RELEASE IPCONFIG /RENEW IPCONFIG /ALL If the machine is still unable to obtain an IP address, then there are several things that could be causing the problem. For example, the DHCP server might have already given out all of its addresses. You can check the servers logs to see if this is the case. Another possible cause is that you might have a bad network cable. Try attaching another machine to the network cable / network jack that the malfunctioning machine is attached to and see if the known good machine is able to attach to the network. Still another possible problem is that the network card is not installed correctly through Windows. In most cases, Windows XP will automatically detect a network card and load the drivers for it automatically. However, Windows XP is notorious for misidentifying network cards. If you are having trouble attaching to the network, it might be a good idea to pop the computers case open and check to make sure that the make and model of the network card thats installed matches the driver that is loaded into Windows. If the driver matches and you are still having problems, try going to the network card manufacturers Web site and downloading the newest driver for the card. I have seen several situations in which a new driver fixed the problem If you have tried everything that I have suggested and are still unable to acquire an IP address, try reseating or replacing the network card. Network cards have been known to go bad for no apparent reason.

Communications Failure
If your NIC has an IP address associated with it, but the machine is unable to communicate across the network, then you will have to use a slightly different approach to troubleshooting the problem. The first question that you need to consider is the source of the IP address. Was the address entered manually into Windows, or was it leased from a DHCP Server? If the address came from a DHCP server, then you can eliminate a lot of possible causes of the problem right now. If the machine is able to lease an IP address, then it means that the computers network card is functioning and that the connection to the switch is good. Dont be deceived though. When a computer leases an address from a DHCP Server, the lease is valid for a specific period of time. If the machine has successfully leased the address in the past, but the lease has not yet expired, then it might appear that the machine has obtained a lease, when in reality the machine is holding onto an IP address that it acquired during a previous session. The easiest way to find out for sure what is going on is to use the IPCONFIG /RELEASE and the IPCONFIG /RENEW commands to get rid of the old lease and acquire a new one. If the NIC has an IP address, but the address has been assigned manually, then the first thing that you will need to do is to perform some basic connectivity tests. You can do this in much the same way as I talked about earlier. Try plugging a known good PC into the network connection to make sure that the connection is good. Make sure that the NIC has the correct drivers. In essence, you will want to make sure that your hardware is functioning before you continue. Once you have done some basic hardware testing, open a Command Prompt window and try pinging the computers own IP address. If the ping is successful, then it means that the TCP/IP protocol stack is at least functional. If you receive an error message stating Destination Host Unreachable then it means that there is something wrong with the way that the machine is set up. It could be that Windows doesnt recognize the network card, or it could be that a necessary system file has been deleted or corrupted. You might try removing and re-installing the network card and its drivers. If that doesnt work, try re-applying the Windows Service Pack since doing so will refresh all of the system files. Assuming that the machine is able to ping itself, try pinging another machine on your network by IP address. If your machine is able to ping itself, but is not able to ping another computer on the network (by IP address) then I recommend trying to ping a few more computers. If you are not able to establish communications with any of them, then look for a bad network link or perhaps a bad network card. If you are able to successfully ping other machines on your network by IP address, try pinging those machines by hostname. If you dont know the hostname, then you could use the ping /a command against the machines IP address to resolve the address to a host name. Another alternative is to ping a Web site. Most Web hosts block pings, but as of the time that this article was written, www.espn.com would still respond to pings. If you are able to ping machines on your network and on the Internet by host name, then your machine is successfully communicating. If you can ping by IP address but not by hostname, then the problem is probably DNS related. Enter the IPCONFIG /ALL command to make sure that your machine is configured to use a DNS server. If there is a DNS server specified, make sure that the DNS servers IP address has been entered correctly. If everything appears normally, try pinging the DNS server to make sure that you can communicate with it.

If you can ping the DNS server, the DNS servers IP address has been entered correctly, and the DNS server seems to be resolving addresses for other people on your network, then the problem probably isnt DNS related. I recommend checking your HOSTS file. It is located in the C:\WINDOWS\SYSTEM32\DRIVERS\ETC folder. The HOSTS file is a legacy component of TCP/IP that really isnt used anymore. It was previously used to associate a Web site with an IP address before DNS became popular. Today, a lot of browser hijackers and various forms of spyware work by altering the hosts file. Try displaying the HOSTS file through Notepad. You might be surprised at what you see. If you see entries that shouldnt be there, you can either delete them or delete the entire HOSTS file.

Conclusion
In this article, I have explained that configuration problems can prevent TCP/IP from functioning correctly. I then went on to discuss the TCP/IP troubleshooting process.

Checking: PC not shown in Network Neigborhood

Date Launched: Nov 03, 1997 Last Updated: Nov 03, 1997 Section: Author: Company:

<img> A few basic item to check, when setting up a Windows 95 network and you cannot see the other PC's in the Network Neighborhood: * is "MS File and Printer Sharing" installed ? * Did you "share" something , a printer or a full disk or a directory? (only system with 'something' to offer show up in the Network Neighborhood) * Did you install on ALL systems "MS NetNEUI as protocol ? (the systems do NOT understand each other, if they have not the same protocol installed, and the limited Windows95-Server module "MS File and Printer Sharing" works best with the "MS NetBEUI" protocol).

* If you use IPX protocol, did you configure IPX Frame Typ ? * If you use TCP/IP protocol, can you PING the other systems(s) ? Can you PING in BOTH directions (sometimes PING works only in ONE direction) * Are the systems part of the SAME workgroup ? Typed EXACTLY the same ? * Make sure, that the computer names are UNIQUE on the network (i.e. if 2 or more system have the same name , it does NOT work, they cannot talk to each other) If all of the above is configure properly, verify whether you have a hardware problem by making the Test by Connection using TCP/IP or using NET DIAG: * if you can 'ping' the other systems, then you have to continue to check your software configuration. * if 'ping' does not get an echo, check your network hardware (did Windows 95 properly detect the IRQ of your network board, did you properly configure/select the proper plug on a MultiConnector Board, do you have the proper cable ('straight'/'crossed' when using Twisted Pair Ethernet (10baseT/UTP)), did you properly 'terminated' the coax-cable of Thin Ethernet (10base2) ? it may also be caused by a different Network Ground/power ground level.

Testing Connection using "NET DIAG"

Date Launched: Sep 16, 2001 Last Updated: Sep 16, 2001 Section: Author: Company:

<img> Once you have setup your network and it does not work, you will need to determine, whether you have a 'hardware' problem (network-board, cables,..) or a software problem (drivers, sharing,...). When you install a Windows95 networking, also some command-line programs are installed. The 'net' command offers a lot of parameters, but has a powerful diagnostic option (you can also you the TCP/IP 'ping' test):

On the first system, open a DOS-windows and type: net diag

If multiple protocols are installed, select the one to be used for the test. Since this is the first system running the test, there is no answer from the network. Answering now with 'N' will install a 'Diagnostic Server'. On the other system(s), enter also a DOS-window and type also: net diag:

Again, define the protocol,if asked. If the network hardware is in good condition, the 'net diag' on this station should now locate the 'Diagnostic Server' on the other system and display a message like above, then you need to check the software-setup.

If you are asked again, whether the 'Diagnostic server is already running', then there was no communication and you have to check your hardware.

The Network is slow !

Date Launched: Oct 31, 1997 Last Updated: Oct 31, 1997 Section: Author: Company:

<img> You have installed your new network (or expanded your existing configuration) and expect a "fast" communication (like a "cheetah): but the connection is not that fast, it appears to be "very slow"/"dead-slow" (crawling slowly as a caterpillar): (if it is TCP/IP and fast in one direction,but slow in the other, it could be the Registry) Lets have a look, on how a "healthy" network should work: (this is an animated GIF, which takes a while to load):

Since animated GIF's don't "print" very well (and I intend to use printouts of these pages as training material), lets have a more static look at the communication process:

The Client has a REQUEST (could be to list a directory, open a file, read/write a file, make a print,..)

The REQUEST is put into a Network-"Envelope"

The "Envelope" is transmitted as an electrical signal on the Ethernet-cable to the "server" system.

The "server" receives the "envelope"

The "server" executes the requests and generates an answer

The answer is put in an "envelope"

The "envelope" with the "answer" is send back to the client

The client receives the "envelope", opens it and has his "answer".

But due to a problem on the wiring, you are getting: (this is another animated GIF, taking even longer to load):

Again, lets look a more "static" loop at all the steps:

The Client has a REQUEST (could be to list a directory, open a file, read/write a file, make a print,..)

The REQUEST is put into a Network-"Envelope"

The "Envelope" is transmitted as an electrical signal on the Ethernet-cable to the "server" system, but gets "damaged".

The "server" receives the "envelope", but due to the "damage" is not able to understand the "request" and does therefor NOT generate an "answer"

Since the "server" did not understand the "request", no answer came back, so finally (after a some waiting), the "Client" assumes: "the envelope was lost" (Time-out)

The "client" repeats the "request".

Due to the "waiting" time ( until the "Time-out" on the Client ) and the time to re-transmit, the networks appears to be : SLOW ! In such cases, make the statistical check with: NET DIAG /STATUS (Is the Network-Connection "healthy" ?) Ethernet Packets ("envelopes") get usually damaged due to bad hardware: - bad NIC (Network Interface card) - missing/bad terminators/hub-ports - cable too long - bad T-connectors But there is also a possibility to slow down the network with Registry settings: - TCP/IP Registry settings