Don’t Assume You Know the Problem

We recently went on a call that we knew there was probably something wrong with the physical network because the client’s inhouse tech support team said so.  Level 1 and 2 tech support are in house for this client and they usually do a good job of troubleshooting.  This case was no different, so the diagnosis we were given was reliable.   In ITIL methodology there are incidents (the thing that happened) and there are problems (the cause of the incident).  Confusing the two can lead to headaches.

Lesson One: Test your conclusions thoroughly

The incident described was that there was a printer on location that could not print.  The diagnosis revealed no link lights on either the device or the switch and swapping ports on the wall did no good.  So that tells me normally that the device has a problem.  Well, the in house level 2 tech support eliminated that issue when they instructed the onsite employee to directly connect a known good computer to the network drops in question.  The computer did not get a link either, so that tells you that both drops are bad.  Good Level 2 support.  I felt confident that their diagnosis was good.

Lesson Two: Be Prepared

A few days ago, we had a series of rain and thunderstorms that rolled through the area because of a hurricane on the east coast, so any number of weird lightning-related things could have happened.  I had already been to this site once to replace a bad switch, so this was not going to be a simple unbox and replace scenario.  So, knowing that I may have to replace fried lines or troubleshoot a whole network, I brought all my trace tools, squawker, a spool of wire, my hole saw, and even my laptop.  Oh yeah, and don’t forget RJ-45 connectors, pin-out diagram (because you DO forget sometimes), and, of course, cable ties.  I checked my batteries on my squawker, listener, network tool, flashlight, and my stud finder.  Yes, sometimes you need to find studs and electrical in the walls.

Lesson Three: Don’t Assume You Know the Problem

When I arrived onsite, I had already tested continuity on the patch cables I would be using.  They are colored purple, so I know they are mine.  Most places have blue, yellow, black, or gray.  Sometimes you will find a green or a red, but I don’t remember going onsite and finding purple patch cables.  Someone let me know if you have.  I’d like to hear that story.

Once I got set up with my purple patch cables connected to my continuity tester and my punch-down tool, shears, etc. laid out where I could get to them, I was underway.  This location has a great setup.  Their network closet is spacious, air conditioned, and well-lit.  So, I knew I was going to be comfortable while working.  Here is a quick thank you to the client for excellent working conditions in an area that seldom gets any love.

When I arrived in the office, I found the wall plate intact with no damage and tested the ports. D8 and D9 were present in the wall plate. No link light was present on printer or on the switch for either port. The continuity tester revealed that D8 tested bad on Pin 1 and D9 tested bad on Pin 8.  I assumed the keystones (actual network plugs that go into the wall plates) to be bad for both, so I replaced the keystone on D9 and, like a good technician, I tested it.  It still tested bad on Pin 8, so I re-seated it.  That’s fancy speak for,”I started over and did it again.”  When that didn’t work either, I traced the line using two keystones (one on each end) and it tested good, so the fault was not in the keystones or the line (as I had begun to suspect), but it was in the patch panel. Ports 8 and 9 were both bad.

I switched the ports being used in the patch panel from 8 and 9 to ports 13 and 14, tested them and labeled them.  I moved over by a factor of 5 because I did not trust the ports that were sharing the little circuit board that they are connected to.  So, I went to the circuit board next to it and was rewarded with trouble free replacement.

If you are curious about how to do any of these steps I described, I have linked to pages that are good instructions for diagnosing a network and for doing individual parts of the job.  More technical descriptions are toward the bottom.

It is always a pleasure helping an organization in need, and this job was no exception.  If you find yourself in need of help with your network or anything else related to computing.  Give us a call.


or email us

Steps for troubleshooting wired home [or work] networks.  If you don’t have an HP just ignore the steps talking about  HP support assistant.  I don’t endorse HP products usually, but their help guides are well written, so I include them here.
Windows 10 Click Here
Windows 8 Click Here
Windows 7 Click Here

Steps for troubleshooting wireless or wired home [or work] networks (from Dell):  Again, if you don’t have a Dell (too bad), but just ignore the steps describing Dell diagnostic tools.

How to Test Network Cables using a cable/continuity tester:

How to install a network keystone:
How to punch down a patch panel: