Shamelessly ripped from NZLUG:
Brief info on common dial-up errors and how to solve them.
"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:
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...
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)