[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: com(4) dialout device behavior change?
"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
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.
Main Index |
Thread Index |