Is your modem plugged in and responding?

Internal or external modem? Whether you are using an internal or an external modem is immaterial. Both will use a single "comm" port. In Linux, "comm" ports are the (usually) default 2 serial ports on your system. One means of checking you serial ports is using the dmesg command. Typing this: "dmesg|grep ttyS"

debian # dmesg |grep ttyS
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
                    

will show you your serial ports. They should be S0 and S1 which translate to COM1 and COM2 in DOS. Once you know which serial ports are active on your system, you can try to make contact with them to determine which has the modem attached. We'll assume you have attached the modem to COM1, the first serial port.

Now starts the fun. Using a program called "minicom", try to make contact with the serial port 1. You will no doubt have to read the instructions for minicom, but the simplest form involves starting minicom as follows:

minicom /dev/ttyS0
                    

This should bring you to a "blank" screen.

Now, once we have this we should be able to issue the modem with commands. These commands emanate from a command set called Hayes. Do a search on Google for the word Hayes and this will bring up a full set of Hayes commands. Whether your modem supports the full set of Hayes commands, or a subset, is should respond to those we plan to issue to it.

So go ahead, and issue the following command:

atz
                    

This should respond with something akin to "Initializing modem".

Then try:

atdt <some-telephone-number>
                    

This should start dialing the telephone number you have entered. To stop the dial process, issue a sequence of 3 "+" characters as follows:

"+++"
                    

Things to note:

Can you dial out manually

Right. Now that you have verified that you can dial out, you need to try to dial to your ISP. This will require that you know their number. Try it now. If it works, and they are running PPP on their side (waiting for your call), there should be a whole stack of junk printed to your screen. If this works, then we are on the road. Sometimes, the ISP will prompt you for a username and a password. Try entering your username and password. Don't worry if it starts sending you lots of junk again. As long as it's authenticating you, you are in business. Hang-up with the "+++" as before.

Are you using a chat script?

Chat scripts are used to perform the dial process. All this stuff we have been doing manually, will need to be done by a chat script. Chat scripts are funny beasties. In essence, there is a "send" section, and an "expect" section. In other words, I send you "A", and I expect "B" in reply. A typical example may be:

<expect>	login:
<send>		username
<expect>	password:
<send>		blah blah (you password here of course)
<expect>	welcome to QED Technologies ISP
<send>		(nothing)
<expect>	Etc. Etc.
                    

Once this process is complete, you should have authenticated. To find out more about chat scripts, consult the manpage for chat (man 8 chat).

Testing you chat script is a little tricky. In essence, you can only test it when dialing up to the ISP. Then you need to consult your /var/log/messages (or /var/log/syslog in Debian) to see what it is trying to do.

How are you authenticating at the ISP?

Two methods of authentication are used by ISP. PAP or the Password Authentication Protocol and CHAP, the Challenge Handshake Access Protocol. Most ISP's nowadays use PAP rather than CHAP, but find out from you ISP which they use. There are two files in /etc/ppp that handle authentication. Pap.secrets and chap.secrets. Both these files have identical formats, so one clever trick is to link one to the other. That way, whether your ISP uses CHAP or PAP, the file will be there. The general format of the file is:

client		server	secret			IP addresses
"hamish"	*		\
                        "my-most-secret-password"	*
                    

Now, the username I will be authenticating with is "hamish", to any (*) server with the secret "my-most-secret-password" and for any (*) IP address. Since chap-secrets and pap-secrets are linked, authentication can happen one way or another. Once the CHAT script is complete, the PPP daemon will be started. Pppd will authenticate using one of these two methods. PPPd has it's own configuration file, namely the /etc/ppp/options file. In this file goes all the options that pppd will need in order to set up this link. Knowing which options to set and which to leave out is a black art (IMHO). Look at the manpage for pppd (man 8 pppd) for a complete list of options. Expect that you will be making a number of calls to your ISP before this works correctly. When it does work, don't mess with it!-)

Do you get an IP address (or is it assigned statically)?

Modern ISP's issue IP addresses dynamically. That is, once you have authenticated, there is a process of IP address negotiation, as handled by the link control protocol (LCP). Watch your syslog or messages file to get an idea of how the negotiation is happening. If you have authenticated correctly, the pppd will have negotiated an IP address for you. Check this using the ifconfig command. There should be an entry for the ppp0 interface and associated with this should be an IP address.

Can you ping you local IP address?

Right. Now you have the link up, it is time to try to ping your local IP address (ppp0). Do this as normal. If you get a reply, then you have an IP address locally that you can see. As part of the ppp0 interface, you should have a remote IP address too. Check that you can ping that too. If so, you are successfully able to ping across the wide area network link.

Can you do a DIG on a host on the Internet?

Most ISP's will issue you with two DNS server entries. You can check that they are there by cat'ting your /etc/resolv.conf file. If they are, then you should be in business. If not, you will need to contact your ISP to check what their DNS servers are. Of course, you could use ANY DNS servers on the Internet, but the closer you are to the servers, the quicker they respond and the less time you spend waiting. It is probably a good time to DIG a host on the Internet. A sure-fire one is Google, so go ahead and try to resolve www.google.com. If this works, your resolving is working and you can try to ping Google.

Can you ping a host on the Internet?

Try to ping a host on the Internet. Perhaps try to ping Google or some other host you know will be alive. If this works, proceed to step 9. If not, the first place to look will be the resolver. Work your way backward up this list to try to isolate the problems. Remember not all ISP's are equal. There is no "accepted" way of doing things, so one ISP might work differently from another. In all the years I have set up these links, I have yet to find this a totally smooth process. Expect problems and then you may be pleasantly surprised. If you can ping a host on the Internet, fire up your favorite browser and surf away.

Bingo, you're done!