There are any number of reasons that your connection does not work - chat has failed to complete correctly, you have a dirty line, etc. So check your syslog for indications.
A very common problem is that people compile PPP support into the kernel and yet when they try to run pppd, the kernel complains that it does not support ppp! There are a variety of reasons this can occur.
/etc/lilo.conf and rerun lilo.A good check on the kernel can be obtained by issuing the command
uname -a, which should produce a line like
Linux archenland 2.0.28 #2 Thu Feb 13 12:31:37 EST 1997 i586
This gives the kernel version and the date on which this kernel was compiled - which should give you a pretty good idea of what is going on.
If you compiled your kernel ppp support as a module, but did not make
and install the modules, then you can get this error. Check the
kernel-HOWTO and the README file in /usr/src/linux!
Another module connected possibility is that you are expecting required
modules to be automatically loaded, but are not running the kerneld
daemon (which auto-loads and unloads modules on the fly). Check the
kerneld mini-HOWTO for information on setting up kerneld.
You must use ppp-2.2 with kernel version 2.0.x. You can use ppp-2.2 with kernel version 1.2.x (if you patch the kernel) otherwise you must use ppp-2.1.2.
If you are not running pppd as the root user (and pppd is not suid to root), you can receive this message.
There are innumerable variations on this (take a look in comp.os.linux...).
A VERY common mistake is that you have mistyped something in your scripts. The only thing to do here is to make sure you are logging the chat conversation between you Linux PC and the server into your syslog (/var/log/messages) and then go through this line by line to make. You may need to dial into the ppp server manually to check things out again.
You need to check the log against the actual prompts very carefully - and bear in mind that we humans have a tendency to read what we THINK we have typed - not what is actually there!
serial line is not 8 bit clean..."
There are variations on this too - such as serial line looped back
etc., and the cause can be one (or a sequence) of a number of things.
To understand what is going on here, it is necessary to grasp a bit of what is going on behind the scenes in pppd itself.
When pppd starts up, it sends LCP (link control protocol) packets to the remote machine. If it receives a valid response it then goes on to the next stage (using IPCP - IP control protocol packets) and only when this negotiation completes is the actual IP layer started so that you can use the PPP link.
If there is no ppp server operating at the remote end when your PC sends lcp packets, these get reflected by the login process at the far end. As these packets use 8 bits, reflecting them strips the 8th bit (remember, ASCII is a 7 bit code). PPP sees this and complains accordingly.
There are several reasons this reflection can occur.
When your chat script completes, pppd starts on your PC. However, if you have not completed the log in process to the server (including sending any command required to start PPP on the server), PPP will not start.
So, the lcp packets are reflected and you receive this error.
You need to carefully check and correct (if necessary) your chat script (see above).
Some PPP servers require you to enter a command and/or a RETURN after completing the log in process before the remote end starts ppp.
Check your chat script (see above).
If you log in manually and find you need to send a RETURN after this to start PPP, simply add a blank expect/send pair to the end of your chat script (an empty send string actually sends a RETURN).
This one is a bit tricksy!
By default, your Linux pppd is compiled to send a maximum of 10 lcp configuration requests. If the server is a bit slow to start up, all 10 such requests can be sent before the remote PPP is ready to receive them.
On your machine, pppd sees all 10 requests reflected back (with the 8th bit stripped) and exits.
There are two ways round this:-
Add lcp-max-configure 30 to your ppp options. This increases
the maximum number of lcp configure packets pppd sends before giving up.
For really slow server, you may need even more than this.
Alternatively, you can get a bit tricksy in return. You may have noticed that when you logged in by hand to the PPP server and PPP started there, the first character of the ppp garbage that appears was always the tilde character (~).
Using this knowledge we can add a new expect/send pair to the
end of the chat script which expects a tilde and sends nothing. This
would look like:-
\~ ''
Note: as the tilde character has a special meaning in the shell, it must be escaped (and hence the leading backslash).
If pppd refuses to set up a default route, it is because (quite correctly) it refuses remove/replace an existing default route.
The usual reason that this error occurs is that some distributions set up a default route via your Ethernet card as opposed to setting up a specific network route.
See the Linux NAG and the Net2/3 HOWTOs for information on correctly setting up your Ethernet card and associated routes.
An alternative to this is that your LAN uses a gateway/router already and your routing table has been set up to point the default route at this.
Fixing up this last situation can require a fair bit of IP networking knowledge and is beyond the scope of this HOWTO. It is suggested you obtain some expert advice (via the news groups of from someone locally you can ask).
There are many reasons apart from these that ppp fails to connect and/or operate properly.
Look in the PPP FAQ (which is really a series of questions and answers). This is a very comprehensive document and the answers ARE there! From my own (sad) experience, if the answer to your problems is not there, the problem is NOT ppp's fault! In my case I was using an ELF kernel that I had not upgraded to the appropriate kernel modules. I only wasted about 2 days (and most of one night) cursing what had been a perfect PPP server before the light dawned!