Previous Contents Next

Troubleshooting a Linux PPP Connection.

 

Setting Up Your Modem

Linux must be configured for your modem before it can use it. In Red Hat Linux the modem can be configured using a graphical control panel. You must be root to set things up with the control panel. If you logged in as root and the control panel is already visible, continue with the next step. Otherwise, become root and type control-panel & in an xterm.
Then click on the picture of a telephone. This starts the modemtool which will allow you to set the device (serial port) to which your modem is connected. It may also be worth clicking on the "Network Configuration" icon in the control panel to check network settings. Since these tools make changes to various configuration files, do not manually edit any configuration files while they are running.

If you are not running Red Hat, or you need further help, read the appropriate section in the LDP Linux PPP HOWTO

 

If you're not even sure that your modem is doing anything

Check your modem configuration (see above).

You should be able to hear your modem dialing the number and "handshaking" with the modem at the other end. If it is an external modem you should see the lights changing.
If you get nowhere with ppp, here are some things to try:

 

You get an error message saying the system lacks kernel support for PPP

The full error message looks like this:

This system lacks kernel support for PPP. This could be because the PPP kernel module is not loaded, or because the kernel is not configured for PPP. See the README.linux file in the ppp-2.3.5 distribution.

It has been known for this message to be displayed because of errors in PPP configuration files, not because of kernel problems. If the following information in this section leads you to believe the kernel is not at fault, double-check the configuration files.

As mentioned in the introduction, your kernel must either have support for ppp compiled directly into it, or available as a loadable module. The output from the dmesg command should contain lines like this...

PPP: version 2.2.0 (dynamic channel allocation)
PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
PPP line discipline registered.
These are lines from an old kernel (that supports PPP as a loadable module) which I used for this section. Your version number may be higher.

If your kernel supports PPP as a loadable module, problems might occur if for some reason the module isn't being loaded when required. Try

  dmesg | grep kerneld
to see if kerneld (the daemon responsible for automatically loading kernel modules when they are required) is running.

The original version of this HOWTO was written when I was running Red Hat 5.2. I'm now running Red Hat 6.0 and the above command produces no output, despite the fact that the pppd module is successfully loaded. It looks like kerneld is just fired up when needed. I'll add more to this section when I work out what's going on. Meanwhile if you're having problems with Red Hat 6.0, follow the notes below anyway - it can't hurt!

If kerneld is running, look at the file /etc/conf.modules (it might be called modules.conf on your system). This might be a zero-length file, which is no problem, however if it contains a line like

alias ppp0 off
it means that the PPP module is explicitly turned off. Remove this line, reboot your computer and try
pppd call ozemail again.
Lastly, check that the PPP module is actually present on your system. Type modprobe -l | grep ppp. The output should be something like this:
/lib/modules/preferred/net/ppp.o

If you can't find any problems with kerneld (or kmod) you could try loading the PPP module manually. Before proceeding, it might be a good idea to read the man pages for lsmod, insmod and modprobe. If your kernel doesn't support modules it is probably quite an old version. You may be able to get ppp working by compiling a kernel and including support for ppp directly into it. Updating to the latest version of the kernel wouldn't be a bad idea either.

First, see if the ppp module is loaded:
root 1> lsmod

Module         Pages    Used by
nls_cp437          1            1 (autoclean)
vfat               4            1 (autoclean)
Looks like it isn't there. Check to see if there is a ppp module on your computer using the modprobe -l command described above.
OK, so let's try and load ppp...
root 3> insmod ppp
/lib/modules/preferred/net/ppp.o: unresolved symbol slhc_free_R3787e5b9
/lib/modules/preferred/net/ppp.o: unresolved symbol slhc_remember_Rbc0f8a5e
/lib/modules/preferred/net/ppp.o: unresolved symbol slhc_toss_R89ec95b6
/lib/modules/preferred/net/ppp.o: unresolved symbol slhc_uncompress_Ra2ca7e04
/lib/modules/preferred/net/ppp.o: unresolved symbol slhc_compress_R5d6838a9
/lib/modules/preferred/net/ppp.o: unresolved symbol slhc_init_R20741a64
This says it can't load the ppp module because that module calls some external functions which aren't available. Since the names of these functions all start with slhc, let's see if there's an slhc module...
root 4> modprobe -l | grep slhc
/lib/modules/preferred/net/slhc.o
Good. Load it.
root 5> insmod slhc
Now we can try loading ppp again.
root 6> insmod ppp
Sucess! lsmod now says...
root 7> lsmod
Module         Pages    Used by
ppp                5            0
slhc               2    [ppp]   0
nls_cp437          1            1 (autoclean)
vfat               4            1 (autoclean)
Now you should be able to connect...
root 8> pppd call ozemail

 

Error message "Serial link is not 8-bit clean".

The following is excerpted from the FAQ distributed with ppp-2.3.3.

The most common cause is that your connection script hasn't successfully dialled out to the remote system and invoked ppp service there. Instead, pppd is talking to something (a shell or login process on the remote machine, or maybe just the modem) which is only outputting 7-bit characters.

This can also arise with a modem which uses an AT command set if the dial command is issued before pppd is invoked, rather than within a connect script started by pppd. If the serial port is set to 7 bits/character plus parity when the last AT command is issued, the modem serial port will be set to the same setting.

 

PPP maintains a connection, but you can't access the network

You hear the modem handshaking, and it does not hang up, but the command
  ping leonard
responds with
PING leonard (150.203.2.15): 56 data bytes
ping: sendto: Network is unreachable
ping: wrote leonard 64 chars, ret=-1
ping: sendto: Network is unreachable
ping: wrote leonard 64 chars, ret=-1
ping: sendto: Network is unreachable
ping: wrote leonard 64 chars, ret=-1

--- leonard ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
Solution: You probably forgot to add defaultroute to /etc/peers/ozemail
Note:You will get the same output if no connection has been established - do not confuse lack of a connection with lack of a route.

 

The modem hangs up after making a connection

There are several possible reasons for this. If you haven't already done so, turn on debugging then try again and look at /var/log/ppplog.

Here is an example of what happens if you have an auth line in /etc/ppp/options and no noauth line in /etc/ppp/peers/ozemail. This actually happened to me when I tried using netcfg but had not removed the auth line from options. (I have deleted the date and hostname, and inserted line numbers...)

1  pppd[716]: Using interface ppp0
2  pppd[716]: Connect: ppp0 <--> /dev/modem
3  pppd[716]: sent [LCP ConfReq id=0x1 <auth pap> <magic 0xca8ba992> <pcomp> <accomp>]
4  pppd[716]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0x5b3862a8> <pcomp> <accomp>]
5  pppd[716]: sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth pap> <magic 0x5b3862a8> <pcomp> <accomp>]
6  pppd[716]: sent [LCP ConfReq id=0x1 <auth pap> <magic 0xca8ba992> <pcomp> <accomp>]
7  pppd[716]: rcvd [LCP ConfAck id=0x1 <auth pap> <magic 0xca8ba992> <pcomp> <accomp>]
8  pppd[716]: sent [PAP AuthReq id=0x1 user="amcbeal" password="ca1op3x"]
9  pppd[716]: rcvd [PAP AuthReq id=0x2 user="" password=""]
10 pppd[716]: PAP authentication failure for 
11 pppd[716]: sent [PAP AuthNak id=0x2 "Login incorrect"]
12 pppd[716]: sent [LCP TermReq id=0x2 "Authentication failed"]
13 pppd[716]: rcvd [PAP AuthReq id=0x3 user="" password=""]
14 pppd[716]: rcvd [LCP TermAck id=0x2]
15 pppd[716]: Connection terminated.
16 pppd[716]: Exit.
Line 8 is fine. You are sending your username and password to the remote system and asking to be authenticated.
Line 9 is where the error is occuring. Your setup requires the ISP to authenicate itself to you in the same way that you just authenticated yourself to it. But internet service providers do not have a username and password on your system, so they send empty strings. These of course fail so your system rejects them.
So how did the remote system know that you wanted it to authenticate itself? On line 3 you sent it an LCP request containing the string <auth pap>

In case there is any confusion, the auth line in /etc/ppp/options forces the remote system to try and authenticate itself to you. It does not tell your system to authenticate itself to the remote system.

 

No connection established but the modem doesn't hang up

This is another problem that could have many causes. On my system I can create this problem when using netcfg. The ppplog output looks like this
pppd[433]: Using interface ppp0
pppd[433]: Connect: ppp0 <--> /dev/modem
pppd[433]: sent [LCP ConfReq id=0x1 <magic 0x9a413654> <pcomp> <accomp>]
pppd[433]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0x66aefffb> <pcomp> <accomp>]
pppd[433]: sent [LCP ConfRej id=0x1 <auth pap>]
pppd[433]: rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <auth pap> <magic 0x66aefffb> <pcomp> <accomp>]
pppd[433]: sent [LCP ConfRej id=0x2 <auth pap>]
pppd[433]: rcvd [LCP ConfReq id=0x3 <asyncmap 0x0> <auth pap> <magic 0x66aefffb> <pcomp> <accomp>]
pppd[433]: sent [LCP ConfRej id=0x3 <auth pap>]
pppd[433]: rcvd [LCP ConfReq id=0x4 <asyncmap 0x0> <auth pap> <magic 0x66aefffb> <pcomp> <accomp>]
pppd[433]: sent [LCP ConfRej id=0x4 <auth pap>]
pppd[433]: rcvd [LCP ConfReq id=0x5 <asyncmap 0x0> <auth pap> <magic 0x66aefffb> <pcomp> <accomp>]
pppd[433]: sent [LCP ConfRej id=0x5 <auth pap>]
pppd[433]: rcvd [LCP ConfReq id=0x6 <asyncmap 0x0> <auth pap> <magic 0x66aefffb> <pcomp> <accomp>]
pppd[433]: sent [LCP ConfRej id=0x6 <auth pap>]
pppd[433]: rcvd [LCP ConfReq id=0x7 <asyncmap 0x0> <auth pap> <magic 0x66aefffb> <pcomp> <accomp>]
As you can see, the remote system is continually sending a configuration request and we are continually rejecting it, in other words telling it that we are not prepared to authenticate ourselves using PAP. If you have pppd debugging turned on these error messages continue forever until you force the modem to hangup. (Click on the Deactivate button. If that doesn't work, pull the phone plug!) You can see the disk light flashing as the messages are continually written to the log file, gradually filling up your disk.

Check the /etc/sysconfig/network-scripts/ifcfg-ppp0 file. If the PAPNAME= line contains no username, this is the problem. Change it to

PAPNAME=amcbeaal
substituting your own username.
If you are getting this problem while using X-ISP you probably forgot to fill in the User/Name and Remote name panels.

 

A PPP connection is established but you're on the wrong subnet.

See this page
Previous Contents Next