On Fri, 1 Nov 2002, Steven M. Bellovin wrote:

> In message <Pine.NEB.4.33.0211011033400.20030-100000@vespasia.home-net.internet
> connect.net>, Bill Studenmund writes:
> >
> >> 2.  If I enable DSR/DTR handshaking, whenever the terminal tries to handshak
> >e,
> >> it ends up causing getty to respawn - I suspect NetBSD is seeing it as a
> >> break.
> >
> >That actually would be good. That means that DTR is getting mapped to CD,
> >which is what mdmbuf wants. Mark the port local, and go for it.
> >
> I don't think so.  The "break" key on a terminal sends a "long space"
> signal, i.e., an in-band "bit" that is stretched long enough that it
> causes a framing error because there's no stop bit.  (We're getting far
> afield here of NetBSD, but...  An RS-232 line in idle state is sending
> a constant voltage equivalent to a 1-bit.  A start bit is one bit-time
> worth of a 0-bit, followed by some number (usually 8) bit-times of 0 or
> 1 bits, as needed.  That's followed by one (sometimes more) "stop bits"
> -- idle time, really, when the signal value *must* be 1.  If it isn't,
> a framing error is signaled.  The break key sends about 1/4 second of
> 0-bit, enough to cause a framing error at any baud rate.  It's thus a
> speed-independent signal of *something*.  It has nothing to do with DTR
> or CD, and in fact can be sent on 3-wire interfaces with no control
> leads.)

A break wouldn't cause the getty to respawn, though -- it would drop
into the debugger. So it isn't actually a break. Dropping CD would
cause the getty to respawn, so it could actually be what Bill said, so
"stty clocal -hup mdmbuf" might work.

Frederick