On Fri, 1 Nov 2002, Peter Seebach wrote:

> So, I managed to get a terminal - an old WYSE 160.  It mostly works pretty
> well as a serial port gizmo, with a couple of problems.
>
> 1.  The terminal doesn't appear to support CTS/RTS handshaking; it supports
> DSR/DTR.  (Either that, or this is a DCE/DTE line naming convention thing,
> and it *should* work, but...)
> 2.  If I enable DSR/DTR handshaking, whenever the terminal tries to handshake,
> it ends up causing getty to respawn - I suspect NetBSD is seeing it as a
> break.
> 3.  There seems to be no way to indicate that a given terminal should
> have xon/xoff handshaking enabled.
> 4.  ssh seems to unconditionally disable xon and xoff!

To address the last point, first, and work up: (4) I don't think
that's the case. I can ssh from a VT420. Listing a large file is
painfully slow, as the VT dutifully sends the xoff every 128
characters, but the display doesn't get corrupted, or log me out,
or anything like that.

(3) You can set up the serial port for the getty by setting the
argument to getty in "/etc/ttys" to a custom entry in "/etc/gettytab".
There are no entries that use xon/xoff in the file as shipped. Here's
the one I use for the VT:

vt.9600|vt420-9600:\
        :sp#9600:i0#2f02:i1#2f02:

Not that it's not an issue once you log in, as you can then use
friendly "stty". Afterwards, "stty -g", can help tell you what numbers
to put in the gettytab entry. "gettytab" also accepts some plain
english in the "#iN" entries, but the last time I tried it, it didn't
accept everything that "stty" did.

All that really does is keep messages to go directly to the console
from getting garbled. If the only issues arise after you log in,
you can do it all with "stty".

(2) Maybe the terminal/cable is doing something silly with DSR and CD,
even in XON/XOFF mode? Try to disable modem control with "stty
clocal", or "stty -hupcl" (or both).

(1) I don't see anything in "stty -a" that looks like DSR/DTR.
I don't think you can use hardware handshaking in a console anyhow,
unless it's a BIOS supported console (logins, yes, but not for the
boot prompt, or ddb).

> As a result, there appears to be no reasonably standard way to set this
> terminal up to work as a reliable console device.  If it's set for hardware
> handshaking, it blows up, and if it's set for software, I can't ssh from
> the window it opens.
>
> Has anyone got clever suggestions?  My preferred solution would be to get
> hardware handshaking working, but that appears to involve debugging a setting
> I haven't figured out yet.

Frederick