Current-Users archive

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

Re: com(4) dialout device behavior change?

"John D. Baker" <> 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

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

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.

Home | Main Index | Thread Index | Old Index