Shamelessly ripped from NZLUG:

Brief info on common dial-up errors and how to solve them.

Error message: "LCP config-request sending timeouts" or similar, also "...not 8-bit clean"

Solution/Info

"After the chat script finishes, the local box starts up the pppd daemon. The pppd daemon immediately fires off 30 handshaking requests (LCP config requests) to the remote end. Then pppd waits for a reply from the remote end...

Quite a few remote ISP servers (well most actually) have a time lag between user authentication, and starting up their ppp daemon. So, the local machine fires off 30 requests, but no ppp is yet listening on the remote machine - the packets get 'dropped'. When ppp starts on theremote server, it waits for incoming LCP config requests, while the local machine is still waiting for a reply from its 'dropped' packets.Stalemate! In the end one (or both) machines timeout (Timeout LCP config request).

There are two solutions:

• Make the local machine send out lots more LCP config requests in the hope of being more likely to catch the remote ppp when it comes up.
• (Preferred) Make chat wait until ppp comes up on the remote machine, then start pppd on the local machine.

To make chat wait, add something like this to the chat script (after login is complete)

Wait for: End chat script

(pppd starts)

The (tilde) is usually the first character of the incoming garbage that occurs when ppp starts on the remote machine. By waiting for it to be received, we know ppp has started on the remote machine.

-- Andrew Simpson

Also try reading /usr/share/doc/pppd/FAQ - it discusses most of the error messages. I got the "... not 8-bit clean" message every time I tried to dial up, and I couldn't figure out why for a LOOONG time. I eventually traced it to the ISP changing their dial-up phone number, but leaving a modem on the old number that would take the username and password, and then not start a ppp session at all. (At least, I hope it was the ISP...). pppd didn't receive anything back after the chatscript finished, and instead of saying "nothing received" it said "serial link is not 8-bit clean". What a completely misleading error message...

Reconnecting ppp when persist and maxfail, erm, fail

Add a line like this to /etc/crontab

• * * * * root if [ "`/bin/pidof pppd`" == ""?; then /usr/bin/pon paradise; fi

This will check every minute to see if pppd is still running. If it's not, it will restart it (replace /usr/bin/pon paradise with whatever you need to do to restablish your connection)

(Thanks to JamesSpooner for the most elegant solution)