Hands on: Iron out networking blips

Not all networking problems turn out to be as complex as they may at first seem

I want to start with a couple of cautionary tales which show the importance of not taking anything for granted when troubleshooting network problems.

The first involves a notebook PC which I need to connect to my wireless network at home ­ a fairly simple procedure and one I’ve completed successfully many times. This time, however, it didn’t go so smoothly.

Connecting the notebook to my wireless router was easy enough. It was running Vista and had an 802.11g Wifi interface built-in, so as soon as I booted it I was presented with a list of available wireless networks. I selected my own, typed in the appropriate encryption key, and the notebook was given an IP address in exchange, enabling me to start browsing the web.

When I tried to connect to my Network Attached Storage (Nas) appliance, however, I couldn’t see it. Indeed, as far as the notebook was concerned it was the only other device on the Lan, apart from the router.

I then made a fundamental mistake and began troubleshooting the problem at the notebook end without checking anything else, starting with the settings in the Vista Network and Sharing Center. However, all seemed in order and none of the changes I made had any effect.

My next thought was that it was something to do with firewall, so I disabled this, but no change. Even when I disabled other security software on the notebook and re-booted, just in case, I still couldn’t see anything on the network.

Finally I went into the room where the Nas appliance was located and found that it was powered off, as was my network printer and almost every other device on the network. And then I remembered the electrician who had been in earlier and had needed to turn the power off to install a new light ­ although I have UPS (Uninterruptible Power Supply) protection for one or two key devices, the Nas box isn’t one of them.

Had I made this check first I could have saved 30 minutes of fiddling. Of course I could also have pinged the Nas appliance first to make sure it was there, but that too can be misleading. As in my second cautionary tale, involving a device that appeared to be on the network but, in reality, wasn’t.

Playing ping pong
I was called in to troubleshoot an issue with a network device attached to a photocopier. Whenever the copier was used it would prompt the user for an account code. It would then log that information, together with the number of pages being copied, to a network database. Customers could then be charged for any copies made on their behalf.

The company (an engineering firm) had installed two of these devices and configured both with appropriate IP addresses using the management software provided. One was working correctly but the other was reported as disconnected. Moreover, although it was possible to ping both devices, they were only able to telnet into one, the other simply refusing the remote connection.

This time I started with the basics and physically disconnected the problem device from the network ­ only to discover that I still got a response when I pinged its address.

The device had stopped working (I later discovered the Ethernet interface had failed) and its address had then been assigned by the DHCP server to a new PC on the network.

That’s something I could also have established by adding the ‘-a’ switch to the ping command to resolve the IP address to a hostname, where the address 10.0.0.10 is resolved to a hostname of Dim9200.

Because the original device had stopped working there was no address conflict and no error messages were displayed.

And, as far as the management software was concerned, the device it expected to see at that address was still there ­ it just couldn’t manage it so reported it disconnected.

When I swapped the unit for a new one and assigned it a different address, the problem went away.
This proves that you shouldn’t take anything for granted with networks and that what appear to be intractable problems can often be caused by something easy to fix.

Wireless tips
Next, I want to share a couple of wireless networking tips, based on favours I’ve done recently for family and friends.

Once I was asked the best way of extending the range of a wireless router to enable someone in a neighbouring house to connect to it. The two houses are about four metres apart so it ought to be possible. Moreover, the distance between the router and its clients could never be more than 10 metres. However, with two brick walls, cavity insulation and other obstructions it was proving difficult to even detect a signal, let alone connect to the router from the adjacent property.

The options, as I saw them, were to run a cable between the two houses, install a wireless bridge, or upgrade the router to something with greater range. A cable would have provided a result but the installation would have required time and effort. A wireless bridge would, similarly, have taken time to install, plus would require extra hardware. So, as the existing 802.11g router was old and proving unreliable, we opted to replace it with an 802.11n device which, in theory, would be superior in terms of range.

The router also came with an 802.11n USB adapter to plug into our client notebook. However, despite having splashed out on the latest gadgetry, the signal was still poor. We could connect, but the signal frequently dropped. Until, that is, we turned the router on its side.

This boosted the signal so much that we went from hardly any connectivity to 100 per cent link quality. By experimenting with the router’s positioning we got excellent signal strength throughout the adjacent property, both using the 802.11n adapter and with ordinary 802.11g equipped clients.

Encryption rules
There are many times I’ve been asked to sort out wireless network problems only to find encryption the real issue. I can say virtually every wireless problem I’ve had to deal with has been down to encryption in some way, the most common issue being unable to remember the key required for access, usually because the router was configured months or years earlier. That’s closely followed by not realising that a key is required at all with, in third place, mistyping the key when setting up the client connection.

I often see the wireless client appears to connect to the host router or access point, but it takes a long time. Plus, depending on the version of Windows involved, you may also get a message saying that you have limited connectivity. You can’t then surf the internet or see anything on the Lan, nor is it possible to ping the internet gateway or anything else normally accessible on the network.

Delve a little deeper ­ using the ipconfig /all command, for example ­ and you’ll discover that although the PC has an IP address, it’s nothing like the addresses used elsewhere on the Lan, typically, starting “169.254”.

What’s usually happened is the Wifi adapter in the PC has been able to establish a basic wireless connection to the host router or access point.

However, because it doesn’t have a matching encryption key, it can’t then interpret the data being passed over that link, including the IP address to use, normally issued by the DHCP server in the internet router.

Windows will then generate its own address (called an autoconfiguration address) and will continue to keep asking for a proper address from the DHCP server at regular intervals, which is all very well but in this instance of no value.

Screen 4 shows what you’ll see if you type ipconfig /all into a command window. Note the IPv4 address entry, which is prefixed “Autoconfiguration” and which starts 169.254.

Troubleshooting this kind of problem starts with trying to establish what key should have been specified and re-configuring the client connection to use it. In a lot of cases that will fix the problem. If it doesn’t or nobody knows what the key should be, go back to basics and start poking around on the router or access point. You can often see what keys have been configured via the management interface or, if the entries are masked, re-set the key to something you know.

That should fix things but if the problem persists, turn encryption off altogether and start again.