Quinn Ebert

As a very-experienced computer user, I have had more than my share of network-related problems.  For those of us new to me and/or my “geeky” ways, you might be interested to know that I have a multi-room, fully-wired network in my home, so things are a bit more complicated for me here than they might be for (some) of you.  As a result of this complexity, of course, I have to deal with problems now-and-then.  However, there seems to be a good “pattern” you can follow for troubleshooting networking problems when they arise.  Since I have worked for a few local businesses troubleshooting their network problems in the past, I will try and lay out my “pattern” for network troubleshooting for you here…

Please Note: While I *am* laying out my troubleshooting “pattern” for you here using instructions for Ethernet-based networks, most modern operating systems (Mac OS X and Windows, anyway) don’t make too much of a distinction about the networking configuration methods — You should find these instructions work well for most NIC types (be they wired or wireless).

STEP 1: Verify there’s a real problem: In my experience with my clients, I find the quickest way to begin “real” troubleshooting is to find out exactly where the networking problems lie.  What I mean when I say this is: Is the machine even connected to the network?  If it is, then, is the Internet connection up?  The quickest way I’ve found to help my clients figure this out for me has been to, first, have them try to pull up the Google homepage (www.Google.com).  If that works, I like to make sure it isn’t just their browser’s cache showing an old copy of the Google homepage; to do this, I have them search for something on Google (don’t ask me why, but the phrase “green parrots” is one of my favourites).  Luckily for my customers (and not so luckily for me, maybe), at least one of these two steps usually doesn’t work — We then have to figure out where the communication breakdown is in their system.

STEP 2: Gather network information: At this point, I know the client *does* have a networking problem.  Next up, I need some more information to help the client with their problem.  First of all, I need to know if the client’s networking adapter has an IP address.  If it does have an IP address, I then want to know their Gateway IP address (which I might need to have them test for connectivity — but, we’ll get to that in a moment).  For my clients (who run Windows operating systems), I would have them run the “ipconfig” command in an MS-DOS/Command Prompt (you can see more information on “ipconfig” in the Multimedia Lectures for this unit — See, Ms. A, I am paying attention!) ;-)  Or, if you run up on a machine running UNIX/Linux, you can use the “ifconfig” command.  These commands will give you the IP address (on both Windows/UNIX) and the gateway address (on Windows — If you have a client running UNIX/Linux, you need to have them run “ip route show” and read you the “default via” line).

STEP 3: If there’s no IP/Address, troubleshoot: If you’re having a really lucky day, having the user run the “Network Connection Repair” function (Windows XP), the “Network Connection Diagnostics/Troubleshooting” (Windows Vista/7), or having them pull and re-plug the network cable and/or reboot their computer will help them re-establish basic network connectivity.  If you’re not having a really lucky day, you might have to get a bit more creative than this (and, you have my sympathies).  ;-)

STEP 4: If you have IP/Address, troubleshoot: Hopefully, you have a good memory for numbers, or you had your client write down their IP address/gateway address, because you’ll be needing them at this point.  First of all, have your client use the “ping” command — also detailed in this unit’s lectures — on their gateway’s IP address — This usually works (if it doesn’t, it’s most likely that the router has hit on a firmware bug, and locked up — it’ll need a reboot, probably, to start working again).  Once you’ve gotten replies from the gateway/router, try pinging something else on their network (you might have to have your client root through the gateway/router interface to find the list of assigned addresses) — Like with pinging the gateway itself, this usually works (one caveat — Windows XP SP2/SP3 firewall blocks pings in the default configuration — This isn’t a 100% foolproof test — But then again, nothing works 100% of the time).  That being sorted out, have the client ping something out on the Internet (I often like to use the IP address of one of the DNS servers at OpenDNS.org — 208.67.222.222).  If/once that works, have them ping a domain name (I like to use google.com and yahoo.com, just like in the multimedia videos for this unit).  :-)  Usually, this is where you’ll have your first big chance of hitting a snag — If these ping tests fail, your client’s DNS servers are probably down (you can walk them through setting up the OpenDNS server shown above, if you want to).

STEP 5: If you’ve made it this far: Have your client open up their web browser to Google again, and search for something new (if they got to search for “green parrots” before, maybe you can suggest “blue alligators” ) ;-)  If you’ve done your job well to this point, your client should thank you for the great research into fun and interesting topics, and then you can both carry on with business as-usual.  :-)