http://www.sqlservercentral.com/blogs/brian_kelley/2013/01/28/consider-all-the-possibilities-when-troubleshooting/

Printed 2014/04/19 11:08AM

Consider All the Possibilities When Troubleshooting

2013/01/28

Wireless LAN

When you are troubleshooting, the rule is if you've checked the obvious possibilities and still haven't solved the problem, it's time to expand to the unlikely ones. This is true even if the evidence would seem to rule out a possibility or if what you have for facts seem to be in conflict. I ran into this yesterday. I was at a friend's church, troubleshooting why a laptop wouldn't access Internet sites. Here's what I saw as the symptoms:

Naturally I went through the normal steps:

When I did the last one, I was getting a response back some of the time, saying the server had received a request it didn't understand. I chalked this up to my being rusty on typing a raw HTTP request on telnet (it's been a couple of years). But even that last one was intermittent. At this point, I had reached the point a couple of others had reached when they had given up. The symptoms weren't connecting up. Five bars + getting some traffic onto the Internet + no IE / Netflix / Windows Update working.

At this point some would ask, "Malware?" There wasn't any sign of it. The AV definitions were out of date and required a contract. That AV package was uninstalled in case it was affecting communications. Still no change. So I listed the possibilities left:

I couldn't rule out any of these possibilities. The first one was what I was leaning towards, especially since I couldn't pick up the wireless network via my iPhone. However, I couldn't rule out the second and third. Speaking of possibilities, the third would be the easiest to rule out. What happened if I connected it via an Ethernet cable? That took us to where the Internet router + wired/wireless switch was. We plugged in the laptop via an Ethernet cable (with the wireless adapter disabled so it couldn't interfere in the event it was faulty) and were promptly rewarded with a various fast display of the websites we tested. OK, that ruled out the third possibility, leaving the first two.

I disconnected the Ethernet cable, re-enabled the wireless adapter, and tried again. Different sites, of course, to escape caching. Lo and behold, it worked. Despite the fact that we saw five bars when connected back at the sound booth, it obviously wasn't getting a strong enough/consistent enough signal to use the wireless network fully. The church had a USB wireless adapter from when they converted an old desktop and we installed it. I disabled the onboard wireless adapter and connected through the USB one. We had a good connection. We walked back to the sound booth and... success. While it was obviously slow, we were able to pull up sites. That established it was a signal strength issue, despite what the OS was telling me. Problem solved, we closed up the day by downloading a free but highly rated AV program and installed it. This included some sizeable downloads, but they worked. Slow, but it worked.

The key to my success where a couple of others had failed was I unwilling to rule out any possibilities until I had run through the steps to test a possibility conclusively. The evidence was conflicting, making troubleshooting difficult. When this is the case, don't rule out the possibilities. Rank them considering their likelihood (given the evidence you do have) and the ease with which you can test and eliminate. Don't eliminate a thing until you can test conclusively.


Copyright © 2002-2014 Simple Talk Publishing. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.