"John D. Baker" <jdba...@consolidated.net> 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.