Networking computers is a pretty complex process, and there are a lot of possibilities for problems. When you have a problem, the symptoms may not always point immediately to the problem. You may be able to avoid solving the problem - maybe you can blame it on somebody else, or maybe you can use a different network technique. But you're better off, in the long term, with finding and solving the problem.
One of the more common symptoms of a networking problem is the dreaded "access denied" error, which is where I started this website long ago. Now access denied, as reported by Windows, can be caused by anything from "I can't identify the address of the resource (server or file) requested" to "The server says that I may not access this file".
Sometimes you have multiple problems, causing your inability to access the other computer. Maybe the cable between your computer and the other computer is bad, AND the other computer is setup so you may not access the file. You have to solve each problem, one at a time.
If you see "access denied", you check the server, and notice that your account is specifically set to not have access, fine. You fix the "you may not have access" setting, try again, and still get "access denied". So now, there are 3 scenarios.
1) You just fixed one problem, and there is another problem.
2) You truly found a problem, but didn't fix it properly.
3) You didn't find the problem, and may have caused another problem by the change you just made.
With scenarios 2 and 3 weighing heaviest in your mind, you reverse the change you just made, since "that didn't fix anything". You then start looking for other possibilities, and find a broken network cable. You buy a new cable, try that, and still get "access denied". Now totally frustrated, you get into the forum of your choice, and whine about "I tried everything, and still have a problem". And you're right - you do have a problem. And the biggest one is that you don't know how to solve problems.
- Solve Network Problems From The Bottom Up
- Test Each Component, and Problem, Individually
- Test Using Previously Tested Components
- Look For Relational Patterns
- Look For Historical Patterns
- Use Diagnostic Aids and Tools
- Research The Problem
- Exercise Patience and Persistence, and Publicise Your Results
Rule One - Solve Network Problems From The Bottom Up
Computer networking is best defined in layers, as you can see from the OSI Network Model. Logical networking, like TCP/IP, connects to physical networking, like Ethernet or WiFi. Server Message Blocks (aka SMBs) provide file sharing, which is what you frequently need help with; and SMBs connect to the logical network in a variety of ways.
If there's a problem with your Ethernet connection, you have to fix that first. In order to fix it, you have to be able to test it. Don't just replace the Ethernet cable, wait a few minutes, and look in Network Neighborhood for everything to become visible. That might work once, but it won't work that way all of the time.
Always diagnose a network problem, one layer at a time.
Rule Two - Test Each Component, and Problem, Individually
When you have a network problem, test each component individually. A physical connectivity test may be simple, such as observing the lights on the router and the network card. Or you may have to get a network tester. Those pretty blinking lights are functional, so use them. And Read The Manual, to find out what diagnostics are available for any product.
But please don't test a physical network problem by looking at Network Neighborhood. There are dozens of possible problems with Network Neighborhood - and physical problems are just one possible cause.
Find out what diagnostics are available for each network component. Test each component, one by one.
Rule Three - Test Using Previously Tested Components
If you have more than one computer, having a spare (never used) network cable, and other components, is not at all a waste of money. Having a spare cable, which you can try at 2:00 in the morning, or when your friends drop by unexpectedly, is well worth the extra expense.
Unfortunately, any unused (totally new) component may not always work - anything you buy may be defective. Worse yet, it may work partially - it may send but not receive. Whenever possible, use components that you have tested. Buy a new cable, if you wish, but take a known good cable from another setup, and put it into the problem setup. Put the new cable into the currently working setup, and test it there first.
If the known good cable (used, from the previously working setup) doesn't work, when used in the currently not working setup, put it back where you got it. Make sure that it continues to work in the previously working setup. It's always possible that you broke it when removing it from the previously working setup. If you now have TWO non working setups, you're going to have to apply these principles to both problems, but separately. Be aware of the possibilities here.
Take the new (previously spare) cable, and test IT in the previously working setup. If it works now, then you can use it in the current problem setup for testing. Then you'll need a second spare, and this discussion could go on still further.
Maybe you have multiple problems. A defective router port, and a bad network cable, is always a possibility. Use known good components, and test one component at a time, when troubleshooting a problem.
Rule Four - Look For Relational Patterns
Diagnosing a network problem can be tricky. If two computers can't communicate, how do you know where the problem is? Is it the first computer, that isn't sending? Or is it the second computer, that isn't receiving? Or could it be both computers (again, compound problems)?
If you have three computers, you're much better off. With three computers, which computer is working differently? Can you access Computer A from Computer B, but not from Computer C? Then look at Computer C first. Or, if Computer A can't be accessed from either B or C, look at Computer A first.
If the problem is intermittent, and involves connectivity interruption, use PingPlotter, running on all computers simultaneously, to look for relational patterns. For Internet Service problems, set PingPlotter pinging a host on the Internet, maybe your ISPs DNS server, or www.yahoo.com. For a LAN problem, ping your router. Compare the output from all computers, periodically. Look for similarities in connectivity interruption.
Rule Five - Look For Historical Patterns
When did the problem start? Did you just apply system upgrades? DOHH. Google for "885250", as an example, to see where this leads.
Does the problem come and go? Is there any pattern there? A time of day, or day of week pattern? Maybe a problem is connected to the weather. Broadband connectivity is not weather transparent - all of the wires involved can be affected by cold / heat, and by dryness / moisture. Maybe the problem is related to your electrical use in your house - coming home, and running the microwave oven, for instance.
One way to look for historical patterns, objectively, is to use Ping Plotter. For Internet Service problems, set PingPlotter pinging a host on the Internet, maybe your ISPs DNS server, or www.yahoo.com. For a LAN problem, ping your router. Examine the output from PingPlotter, and see when and where the problems are occurring.
If PingPlotter shows loss of connection between your router and your IPSs gateway, you have to get your ISP involved. And you don't have to listen to them telling you to fix your computer, because the problem is not between your computer and the router. A picture can be worth a thousand words, if you have to deal with your ISP.
Rule Six - Use Diagnostic Aids and Tools
In order to diagnose a problem, you have to have tools to help. I have a small, carefully chosen suite of software tools, which I inventory in My Personal Toolbox. Other helpers have their own favourites. Find which ones work for you, and always look for others.
Besides software tools, use diagnostics provided by the equipment, and hardware tools, if you have them. The lights on the router, and on the network cards, are a start. Having a network tester is a good idea too.
One of the simplest tests for Internet Protocol connectivity is the ping utility. Whenever you have a problem, almost any expert will eventually ask you to "Ping one computer from the other".
I use CDiag for comprehensive and repetitive testing between multiple computers. CDiag performs simple tests, in combination, between each computer and each other on the LAN, and makes it simpler to assemble all of the symptoms into one report. CDiag is pretty simple - but it can be very useful.
Rule Seven - Research The Problem
With a computer problem, you have a major advantage over a non-computer problem. Computer owners frequently use the web to get help. Unless you live totally on the edge, the chances are that any problem YOU have has already been experienced, and written about, by somebody else. So Google for it. Or ask for help - but ask intelligently.
Rule Eight - Exercise Patience and Persistence, and Publicise Results
If you have a problem, be patient when dealing with other people who help, and in with yourself as you learn. You won't solve any problem by giving up, nor will you get help any faster from someone else. Trust those who try and help you, and provide the diagnostic information that they request, and as they request it. Be tolerant of the diagnostic process, and work with the helpers.
But be persistent too. Followup with anybody who promises to help you. Don't just ask for help, and go away. Wait a while, and ask again.
And be objective - whether you are getting help from a volunteer online, a Tech Support person employed by your employer, or a vendor of a product or service.
If you follow this guide, and you find and fix one problem, but everything still doesn't work, be persistent. Start again from the beginning, and question everything. Go thru this guide in more detail, and look for another problem. And ask for help again, maybe in a different forum.
Come back here from time to time. I write, and rewrite, this blog constantly. That's the advantage of a web document (website) over a book - this is a dynamic medium, and this blog is constantly changing.
And publicise your results. When you get results, or when you don't, let folks know. Everybody benefits from collaboration, and sometimes knowing what doesn't work is as useful as knowing what does.
The Internet is huge, and growing all of the time. Keep at it until everything works, and don't give up. Well, persist to a limit, anyway.