[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: pppd says serial line is not 8 bit clean'!

On Tue, 20 Feb 1996, Billy Chow wrote:
> Thanks, this promted me to look at the /var/log/messages and in there
> I found the following
> [...]
> chat[xxx]: (send pppgate)     <---- 'pppgate' sent here
> chat[xxx]: (expect login:)    <---- now expecting 'login:'
> chat[xxx]: pppgate^M          <---- chat examining buffer contents
> chat[xxx]: login:  -- Got it! <----    for 'login:' - found here      
> chat[xxx]: (send ppp)         <---- 'ppp' sent here
> The (send ppp) line was the last line.  I suspect that the stuff in
> brackets are just chat's preparation, ie, (send ppp) means the command
> ppp wasn't actully sent!  And chat wasn't expecting a string, pppd

I have annotated the chat log above; 'ppp' was sent when you see the (send
ppp) entry.  You may be thinking it wasn't sent because you do not see it 
echoed in the log.  For instance, 'pppgate' shows up in the '(send 
pppgate)' line and again 2 lines down.  The second line is just showing 
the previous buffer contents while searching through it for the expect 

> started negotiation and of course failed because ppp daemon wasn't
> started at the OUCS end.  It seems to me that chat was looking for a
> `expect' string in the script before actually sending ppp.  I tried
> adding "" after ppp in the chat script but the result was exactly the
> same.  chat ignored the last "".
> Do you guys know how to tell chat to expect nothing at the end of the
> script?

The chat sequence is formatted as expect-send *pairs*.  The "expect" 
entry comes before the "send", so after your 'ppp' command is sent, if 
that is the last entry in your script, nothing else is expected.

I saw someone reply indicating that your system may be sending the ppp
negotiation packets before the remote side is ready.  Generally, I have
seen this show up as a 'Serial line appears looped back' error rather than
the '8-bit clean' error.  In that case, though, the loop-back can be
covered up by inserting something like 'sleep 10' right after your chat
command.  This gives the remote system more time to start the ppp process. 

The '8-bit clean' error has me confused.  Actually, the line logged after
that ('Problem: nothing was received') is associated, indicating that no
characters came in on the serial line (not really an 8-bit problem). 
This is just a guess, but try removing the 'asyncmap 0' entry in your
/etc/ppp/options file.  I wonder if there could be a non-escaped control
character messing with your modem???  Also, you may want to turn on more
debugging (pppd debug kdebug 7) and look at the log files again.  This
will give you a dump of all data sent by pppd and all data received on the
serial line (logs can get long though).

And, last, have you used a simple terminal program to manually type in
your connect sequence.  After you respond to the 'login:' with
'ppp<RETURN>', does the remote start sending packets right away or is it
coming back with another prompt or waiting for another key press?  Just 
something you might want to double check if you haven't already.

      * email: Mike_Blatchley@maxtor.com -or- mikeb@maxtor.com *
              * MIME Mail Reader * PGP Key Available *

Reply to: