Ah.... The infamous 8-bit unclean error. Here's what they PPP-HOWTO
says about it:
--- --- --- ---
18.3. The syslog says "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.
18.3.1. You are not correctly logging into the server
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).
18.3.2. You are not starting PPP on the server
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).
18.3.3. The remote PPP process is slow to start
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).
----------
From: kamekudzi
Sent: Thursday, January 28, 1999 8:43 AM
To: LKLawson; 'LINUX-DI@SMTP <[EMAIL PROTECTED]>'
Subject: DIALD HELP WANTED!
I am not particularly a linux guru but I am steadily getting there.
Thanks to
this newsgroup, I have a working PPP connection to my ISP. Now I am in
the
process of getting diald to work. Diald dials out alright and establishes
a
connection but no packets don't seem to be transmitted or received over
the
link. Here is what was logged in the /var/log/messages file. What can be
wrong?
How do I get round this problem?
Thanks.
Kafui.
============
Jan 20 08:08:40 localhost diald[235]: Running connect (pid = 792).
Jan 20 08:08:42 localhost connect: Initializing Modem
Jan 20 08:08:43 localhost connect: Dialing 221093
Jan 20 08:09:01 localhost connect: chat: Jan 20 08:09:01 CONNECT
33600/ARQ/V34/LAPM/V42BIS
Jan 20 08:09:02 localhost connect: Protocol started
Jan 20 08:09:02 localhost diald[235]: Running pppd (pid = 802).
Jan 20 08:09:06 localhost kernel: PPP: version 2.2.0 (dynamic channel
allocation)
Jan 20 08:09:06 localhost kernel: PPP Dynamic channel allocation code
copyright
1995 Caldera, Inc.
Jan 20 08:09:06 localhost kernel: PPP line discipline registered.
Jan 20 08:09:06 localhost kernel: registered device ppp0
Jan 20 08:09:07 localhost pppd[802]: pppd 2.3.5 started by root, uid 0
Jan 20 08:09:07 localhost pppd[802]: Using interface ppp0
Jan 20 08:09:07 localhost pppd[802]: Connect: ppp0 <--> /dev/ttyS0
Jan 20 08:09:37 localhost pppd[802]: LCP: timeout sending Config-Requests
Jan 20 08:09:37 localhost pppd[802]: Connection terminated.
Jan 20 08:09:37 localhost pppd[802]: Receive serial link is not 8-bit
clean:
Jan 20 08:09:37 localhost pppd[802]: Problem: all had bit 7 set to 0
Jan 20 08:09:37 localhost pppd[802]: Hangup (SIGHUP)
Jan 20 08:09:38 localhost pppd[802]: Exit.
Jan 20 08:09:44 localhost diald[235]: Delaying 10 seconds before clear to
dial.
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
