>> Either your connection is losing the top bit on every character, or
>> more likely the other end of the link isn't running PPP (e.g. it is
>> still waiting for you to complete a conventional login sequence).
>Wrong answer? The most likely reason for the serial link not being
>8-bit is that the modem (either or both ends) and/or the login
That's the most likely reason for the link not being 8 bit clean, but we
are not talking about that, we are talking about a particular error
message from pppd, which is often misleading.
Quote:>controller (eg gettty if this refers to a UNIX system) is not set
>for 8 data bits. Try the modem configuration first.
The only time this has ever happened to me was because PPP hadn't
started. What happens is that people try to do a pure PPP connect
to a system that requires a conventional login, or they miss out a step,
often a protocol prompt. Often during the login sequence, the remote
side strips the 8th bit, so that it doesn't have to worry about the
parity of the the terminal, and it echos all the data and prompts
with bit 8 clear.
PPP (free PPP) then reports an LCP timeout sending configure requests,
which people tend to forget to report, and then adds a note that all
the data was 7 bit.
It is possible that most people get this because of really not having an
8 bit clean path, but I would suggest that that is not actually very
common in the typical case of calling an ISP (other cases tend to be
handled by local network support people). I'd also suggest that where
it is a genuine 7 bit channel, the user is likely to resolve the
problemn and not ask. They really start asking when the error message
is misleading. The result of this is that, when this question gets asked
on USENET, the most likely cause is a failed conventional login.
(Sending any email to this site constitutes a licence to copy it to any
company which might reasonably be assumed to have transported it or
might reasonably be assumed to service any addresses quoted in it. 15Sep1996)