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

Re: login and bash on a hardwired terminal.



>>>>> Dale Scheetz <dwarf@polaris.net> writes:

> Thanks to Dirk and Guy, I got getty running on ttyS1 to a Data General
> terminal (ok, ok, but I got it for free. In fact I have 6 of them) but I
> still have problems.

> Pressing return on the terminal causes getty to put up the login message
> and prompt, just as it should. After entering a user name (getty kicks off
> login) a short line of garbage that looks like it would like to say
> Password but actually says:

> P8^w'd

> and then moves up to the previous line and prints:

> dwarf (the user name)

> entering the password for dwarf at this point creates a spew of reverse
> video spam across several lines and eventually produces a reverse video
> prompt. All input typed at the keyboard from this point on is reverse
> video. Anything that I type is displayed ok on the terminal. Anything that
> bash returns to the terminal is hopeless garbage. 

One explanation that would fit this behavior is that your terminal is
configured to expect more stop bits than the linux box is sending.

When you are typing and the linux box is echoing, there are long
pauses (relative to a single bit time) between each character.  With
these pauses, it is irrelevant how many stop bits the linux box sends,
since the stop bits blend in with the pause.  That is, the pause after
a character consists of a bunch of extra stop bits.

However, when the linux box is sending characters as fast as it can,
then the start bit of the next character follows immediately after
however many stop bits were sent previously.

If the receiver is expecting 2 stop bits, and the linux box is only
sending 1, then the receiver will detect framing errors or, if it
ignores framing errors, it will simply get out of sync.  That is why
you see only six characters instead of the 9 in the "Password:"
prompt.

I don't know if ttyS1 can be configured to send more stop bits.
Perhaps your terminal can be configured to expect fewer.

-- 
Steve Preston (spreston@gte.com)


Reply to: