William here. Okay so far I’ve done lots of talking about troubleshooting this network problem. Clearly, there’s some type of problem going on preventing the computer from connecting to the network and the Internet properly. In Step 1, we checked the obvious. In Step 2, we checked the hardware. If you’re experienced at this sort of thing, all the related checks probably took about a minute—maybe less.
To recap the scenario in full:
>>>>>The computer is one of many running on a fairly complex home network. The network has a single router and multiple network switches. When the operating system starts, the computer is unable to connect to the network or to the Internet. The computer is running 64-bit Windows 7 and has a single 1.0 Gbps network adapter.
Normally, this type of problem would be pretty easy to resolve. However, this computer with a single network adapter thinks it is on multiple networks—and therein lies the crux of the problem. What has happened here is at startup, the computer checked the networking configuration, found the adapter, but was unable to determine exactly how the computer was connected to the network. As a result, the computer has no network connectivity and no Internet connectivity whatsoever.
In Step 3, we’ll try to determine whether this is a configuration problem. Often, the fastest way to check for a configuration problem is to use the Command Prompt. Display the networking configuration by entering ipconfig /all. In the output, check the IPv4 (and if appropriate, the IPv6) configuration. For IPv4, look specifically at the following:
- IPv4 address
- Network mask
- Default gateway
- DNS servers
The assigned values should be appropriate for the network to which the computer is connected. If Dynamic Host Configuration Protocol (DHCP) is enabled, the make sure the computer has connected to the appropriate DHCP server. If the computer hasn’t connected to a DHCP server, it will have an IP address in the automatic private IP addressing (APIPA) range: 169.254.0.1 to 169.254.255.254. A computer with an automatic private IP address likely cannot communicate appropriately on the network. As a result, Windows periodically checks for a DHCP server to become available.
If the computer looks like it has the appropriate network settings, try a ping or tracert to the default gateway. In some cases, ping is blocked by firewall settings but the tracert should work regardless. Failure of a ping / tracert here likely would indicate a connection problem between the computer and the default gateway or a problem with the default gateway itself. To resolve a connection problem, you’d check the cabling and switches between the computer and the default gateway.
To resolve a gateway problem, you’d need to look at the device itself to determine its status and configuration and if this is outside your area of expertise, a network admin can help you. However, keep in mind, that you can’t connect to a non-existent gateway. A computer configured on the network 192.168.27.x should have a default gateway of 192.168.27.1 in most cases. However, if the network settings are wrong and the computer is actually on the 192.168.12.x network, pinging 192.168.27.1 likely won’t return results because the correct gateway IP address likely is 192.168.12.1.
If the computer can get to the default gateway, try a ping or tracert of a site on the Internet. Again, in some cases, ping is blocked by firewall settings but the tracert should work regardless. Failure of a ping / tracert here likely would indicate a problem with the Internet connection or Internet service. But you’d need to slice and dice it a bit more to be sure. For example, if you can’t ping / tracert by site name, such as tracert www.yahoo.com, you’d want to ensure this wasn’t a DNS problem.
To check this, you should ping / tracert an external site by its IP address. If you can get to the external site by its IP address but not by its fully qualified name, you likely have a DNS problem. Resolve the DNS problem by verifying the DNS server IP addresses and setting the server IP addresses as appropriate. You may also need to flush the DNS resolver cache. To resolve an Internet connection problem, check the cabling between your internal router and the device that routes to the Internet as well as the status of that device.
In this scenario, the computer has DHCP-assigned IP settings and was able to get the settings from the DHCP server. Because of this, checking the TCP/IP configuration at the command-line seems to provide the correct settings. That said, if you thought the problem was related to the DHCP settings, you could perform a variety of troubleshooting tasks with ipconfig at the command-line. Ipconfig /release, Ipconfig renew, Ipconfig /flushdns, and Ipconfig /registerdns are all handy commands.
If you thought the problem was related to assigned settings, you could review the adapter settings by clicking Control Panel > Network And Internet > Network And Sharing Center > Change Adapter Settings. Then on the Network Connections page, you would right-click the appropriate adapter and then select Properties. In the Properties dialog box, select Internet Protocol Version 4 and click Properties. You can now review the IPv4 configuration.
One way to troubleshoot a networking problem at this stage would be to manually assign IP settings that you know should work. If you are able to manually assign settings and connect to the network and to the Internet, the problem likely is related to DHCP. And the likely suspects:
- Perhaps another computer on the network has/had the same IP address the computer was trying to use.
- Perhaps an incorrect gateway setting prevented the computer from getting to the correct DHCP server.
- Perhaps the DHCP server itself is the problem and inappropriate IP settings were assigned.
Any guesses as to what happens when we manually assign IP settings? Well, it does force the computer to modify its configuration—and more importantly, in this particular case, the problem appears to go away. The network connectivity returns and all looks good. But is everything really okay?
William R. Stanek
williamstanek at aol dot com