Troubleshooting ISP Connection Problems
Pages: 1, 2, 3, 4

If you have accounts on multiple systems, then you will have to replace the second item (first *) with the name for the remote system so your system knows which secret to use for that particular remote system. There are three options for that name.

• You can ask your ISP for a name.

• You can look in /var/log/ppp for a line like pppd[1155]: rcvd [CHAP Challenge id=0x1 <...>, name = "axion"] where ... is a long string of random numbers and letters. That name (axion in this case) is the name the remote system thinks of itself as. CHAP 80 (Microsoft CHAP) does not report the remote system name.

• Or you can assign the remote system an arbitrary name, put the option remotename <TheNameYOuDecidedOn> after the pppd command.

Whichever option you choose, use that name as the second field in the line in the chap-secrets file (or pap-secrets).

If your ISP uses NT, you may have to add a domain name to your user name. Thus, in both the CHAP secrets file and in the "user" option to pppd, instead of <username>, use <domainname/username> instead. (or, in some cases, it has been reported as <domainname\\username>) You will have to get the domain name from your ISP.

[Note that PAP and CHAP also have the option for symmetric authentication, where your machine also requires authentication of the remote system. For most home user systems, this will not be used -- your ISP will refuse to agree to authenticate itself -- and the above is sufficient. If in your /var/log/ppp file you see your system asking the remote system for authentication -- such as a line like

Jan 15 23:10:28 wormhole pppd[511]: sent [LCP ConfReq ... <auth pap> ...

your system sent (not received) a request (ConfReq) for PAP authentication, your system wants the other side to authenticate themselves, which they will almost certainly refuse to do. Put the line

noauth

into your /etc/ppp/options file and remove any options like +chap, +pap, require-pap, require chap, auth from the /etc/ppp/options file or from the pppd command line. Some new versions of pppd may, by default, require the remote system to authenticate itself, and will thus need the noauth option.]

Second, in both the case of PAP and CHAP, you also have to use the "user" option to pppd, to let the remote machine and your machine know what your user name is for PAP/CHAP authentication when looking up secrets in the pap-secrets or chap-secrets files. By default, pppd uses the name of your local machine, which is probably not your user name on the remote machine. So now try

/usr/sbin/pppd /dev/ttyS1 57600 debug user <yourusername> connect "/usr/sbin/chat -v <chatstring>"

where <chatstring> is whichever chat string successfully got you to this point. (Remember that the < and > are not to be included in strings.)

For example, here would be a line for my system

/usr/sbin/pppd /dev/ttyS1 57600 debug user unruh connect "/usr/sbin/chat -v '' ATDT5551234 CONNECT '\d\c' "

Occasionally the remote system is broken, and after they have asked for PAP authentication, they seem to refuse to listen to your system's request for information. The symptom will be that your system will send a whole string of PAP authentication attempts

.... sent [PAP AuthReq id=0x1 user="username" password="password"]
.... sent [PAP AuthReq id=0x2 user="username" password="password"]
....

with no response from the other side.

Try putting the line

asyncmap 0xa0000

or even

default-asyncmap

into your /etc/ppp/options file.

Occasionally, when you read /var/log/ppp, it may seem that the remote end cannot hear you. Your side sends requests to the far side, and the far side keeps sending back the same requests to you. The session will terminate after a while. You may have a misconfigured serial port. Run

setserial /dev/ttyS1

and make sure that the UART listed is actually the same as the one on your serial or modem card. Almost all newer computers (since the mid-90s) use the 16550A UART. This is different from the 16550 UART or 16450.

Are you connected?

You are now, I hope, connected via PPP. The /var/log/ppp file should have a line like

Connect: ppp0 <--> /dev/ttyS1

Now, run

/sbin/route -n

and look for a default (0.0.0.0) option on the ppp0 link -- ppp0 is the last item in the line and 0.0.0.0 is the first. If so, you are connected. If not, you now at least have the far end negotiating for a PPP connection. Your /var/log/ppp file should now have lines that read

sent [LCP ConfReq ... rcvd [LCP ConfAck ... 

pppd will also report in the log file your local and the remote IP addresses. If so, you are connected.

Connected!

At this point you should be connected. You should see lines like

Jan 16 14:54:50 wormhole pppd[905]: local IP address 137.82.66.22
Jan 16 14:54:50 wormhole pppd[905]: remote IP address 137.82.47.122

in the /var/log/ppp file. The above two lines are from my own system. The addresses, names, dates, and times will vary for yours, but the form should be the same.

PPP is now connected.

Bill Unruh works for the Advanced Research Department of the Canadian Institute for Physics and Astronomy.

---

Return to the Linux DevCenter.