Networking

Troubleshooting a dial-up session

What troubleshooting techniques do you employ when you encounter a dial-up problem? If your answer involves throwing darts at a dartboard, then check out this Daily Drill Down by Brien Posey.


These days, more companies are saving money by allowing employees to telecommute. The companies save money on decreased absenteeism and usage of office space and supplies. Of course, the employees can work from the comfort of their own homes, often with flexible hours. However, there is one thing that can put a damper on telecommuting: a telecommunications failure.

When it comes to telecommunications, there are a million different things that can go wrong. Unfortunately, there’s no one solution that can be applied to dial-up networking problems, because there are so many different forms of dial-up networking. For example, a user could be dialing in to a normal RAS server or to a terminal server. Another user could be engaged in a remote control session with his or her desktop PC at the office, and yet another might be dialing in to the Internet and patching through a VPN to interact with the network at the office. Whatever method the employees are using, there are some things that all of these methods have in common. In this Drill Down, I’ll discuss some general procedures that you can use to troubleshoot a variety of dial-up networking problems. In a follow-up Daily Drill Down, I will discuss what to do after you have tried these techniques and you are still having trouble getting connected.

Before I begin
For this Daily Drill Down, I’ll assume that the client is using a Windows 9x client to dial in to a Windows NT or Windows 2000 RAS server. Throughout the article, I’ll use the word client to refer to the end user’s PC and the word server to refer to the machine that the end user is dialing in to. However, just because I’m using these terms doesn’t mean that these techniques will only work in client/server environments. I’ve designed my techniques to be as universal as possible. Therefore, if you’re using some other dial-up method, just substitute the server for the type of machine you’re dialing in to. Even if you’re connecting to the host through a VPN, the client is still dialing in to another modem through an Internet service provider. Although some of the communications techniques may differ, the principles remain the same.

Test the phone line
The first step in the troubleshooting process is to verify that the phone line is working correctly. Doing this on the client end is easy since we can pretty much assume that the dial-up client will always be using a Plain Old Telephone Service (POTS) line. However, depending on your company’s network configuration, the client could be dialing in to just about anything. If you work for a small company, the client is most likely dialing in to an analog modem that’s also connected to a POTS line. However, things get a little trickier if the company uses a VPN connection or a call-forwarding system.

Check the dial tone
To troubleshoot a POTS line that’s connected to an analog modem, the easiest method is to simply plug a regular telephone into the phone jack that’s normally used by the modem. After doing so, listen for a dial tone. If you hear one, try dialing the same phone number that the client usually dials to get into the remote network. As you dial the phone, there are a few different things that you should be listening for: a ring, a busy signal, or nothing at all.

If you don’t hear anything after dialing the remote phone number, there’s a problem with either the client’s phone line or the server’s phone line. To determine on which line the problem exists, try dialing another phone number to see if you can complete a call. If you’re able to talk to someone over the phone, then the phone-line problem exists on the server’s line. If you can’t call anyone, then the problem exists on the client’s line.

Busy signals, unanswered calls, and more
Now, let’s look at some other possibilities. Suppose that you manually dial the server’s phone number and receive a busy signal. The problem is most likely that someone else is already using the phone line. If the server has multiple phone lines that are reachable through a common access number, there’s a good chance all of the available lines are in use.

If you check the server, but the line isn’t busy, then the problem lies elsewhere. Try resetting or temporarily unplugging the server’s modem to see if the busy signal goes away. If the server’s phone lines use a call-forwarding mechanism, I recommend resetting it as well. If resetting everything doesn’t do away with the problem, there may be a problem with the server’s phone lines. For example, a wire could be shorting out or something else could be plugged into an extension of the phone line. If you’re working with an analog phone line, you might be able to plug a phone into the server’s phone line to test it.

Now, suppose that you try to manually dial the server’s phone number and the phone just keeps ringing on the other end, but the server never answers the inbound call. The problem could be that the modem on the other end isn’t plugged in, isn’t getting power, or needs to be reset. It’s also possible that the server isn’t communicating with the modem correctly. To solve this problem, try cycling the power on the server’s modem and verifying that it’s plugged into the power supply, the phone jack, and the server securely. If the modem still isn’t answering the inbound call, there may be a software glitch. If this is the problem, you should stop and restart the remote access service. If you’re using some other type of communication’s software or if stopping and restarting the remote access service doesn’t work, then try rebooting the server.

Check for call waiting or server damage
If the server’s modem still refuses to answer the call, then there are at least two more possibilities. The first possibility is the server’s phone line has call waiting. Normally, server phone lines shouldn’t have call waiting. If it does have it, though, call waiting should be disabled. The reason is if call waiting is enabled, a machine could initiate communications with the server. A second machine could then try to dial in and the server’s phone line would ring off the hook, but the server would never answer. In the meantime, the call waiting beep could temporarily disrupt the communications session that’s already in progress. This disruption could come in the form of a short delay, gibberish, or even a dropped connection.

The second possible reason why the remote server may never answer an inbound call is that the server’s modem may be physically damaged. It could have been struck by lightning, absorbed an electrical surge, or any other number of potential catastrophes. I’ll explain how to diagnose a damaged modem in my follow-up Daily Drill Down.

If all else fails, get a phone-line tester
Although it can be a little tricky to determine whether or not a phone line has gone bad, a little logic can help you to figure it out. Remember that just because a phone line can make or receive calls doesn’t necessarily mean that the phone line is good. I’ve personally seen countless cases in which the phone company wired a phone line incorrectly. In such cases, the phone could make or receive calls, but not both. You can check for such problems with a phone-line tester. Such testers are available at any hardware store for less than $20.

In other cases, I’ve seen communications fail because of static on the phone line. Remember that static doesn’t have to be extreme to disrupt communications. When static is present on a phone line, transfer rates slow down to a pace in which communications are still possible. However, even at the slower speeds, there may be so many retries that communications are unattainable.

Handshake issues
One of the trickier situations I encountered with a dial-up client was one in which all of the phone lines involved seemed to be okay and the server’s modem actually answered the call. However, after the call was answered, the handshake process never completed or gibberish displayed on the screen. This situation may seem extremely frustrating to troubleshoot, but there are some things that you can look for.

First, if you’re using stand-alone communications software such as PC Anywhere, ProComm, or Reach Out, I recommend checking your communications parameters. Make sure both machines are set to use the same number of bits, stop bits, parity settings, etc. If you’re dialing in to a Windows-based server, make sure the client and the server are both set to use the same dial-up network settings (client, protocol, adapter, etc.) and that those communications components are configured correctly.

Once you’ve verified that the communications parameters are correct, move one of the machines to a different physical location and try communications again. The reason for the move is that there are a number of factors that can have a negative impact on communications. For example, older buildings may have low-quality phone lines that were never intended to carry data. Likewise, the phone lines could be experiencing crosstalk from other phone lines or could be getting interference from electrical wires or radio interference. If the phone line has to pass through too many switches, communications can also be disrupted.

There are several things that you can do to combat these types of problems. The best solution is to run new phone lines using high-grade cable and, if necessary, update your company’s phone switches. However, this solution isn’t always practical because of budget, time constraints, or other logistical difficulties. Other less effective ways of coping with the problems include reducing communications speeds and installing phone-line filters at every possible point between the client and the server.

Conclusion
While there are many different forms of dial-up networking, there are components that are common to all dial-up sessions. As well, there are some basic troubleshooting techniques that you can use regardless of the type of dial-up session that your employees are trying to establish. In my follow-up Daily Drill Down, I’ll continue the discussion by explaining some additional troubleshooting techniques.

Editor's Picks