Re: com(4) dialout device behavior change?

[Greg Troxel <gdt%lexort.com@localhost>]

"John D. Baker" <jdbaker%consolidated.net@localhost> writes:

> On a netbsd-8/amd64 system I have no problem using 'cu' to connect to
> the serial console of another system (sparc, netbsd-8.99.37) with a
> "three-wire" serial cable:
>
> Excerpt from "dmesg.boot":
>
>   com0 at acpi0 (UAR1, PNP0501-1): io 0x3f8-0x3ff irq 4
>   com0: ns16550a, working fifo
>
>   $ cu -9600 -l dty00
>
> When I boot the same amd64 host with -current, the same command reports
> "connected", but I have no evidence of characters being transmitted.
> (Subsequently connecting to the remote with SSH shows 'sudo' waiting
> for authentication on the serial console port.  It should have aborted
> after all the newlines I sent to it.)
>
> I seem to recall a change with some of the signals now required before
> dialout devices work.  I'll need to check my adapter to make sure
> everything that I need to loop back is correct.

I am unaware of a change here, but it would be good to read the commit
logs.

Part of the point of dty00 vs tty00, as I realize you understand, is to
be able to connect when DCD is not asserted by the DCE which is attached
to the computer.  But the bigger point is to allow a getty on tty00
waiting for DCD, and to have another process open dty00, and have the
resulting DCD when the modem connects from the dialed-out call be hidden
from tty00.  This was really important when simultaneously supporting
dial-in users and UUCP!

There are related issues about DTR/DSR, and RTS/CTS, which in the RS-232
idea world are expected to be cross-connected even in a null modem.

But you say 3-wire cable, which is also normal, and so obviously they
aren't.

Typically terminal programs have some control over putting ttys in modes
to ignore dtr/dsr.   So I wonder if the ignoring of DCD is working ok,
and you have having DSR or RTS/CTS problems.