pjt@cpac.washington.edu (Larry Setlow) (10/03/90)
I haven't seen anybody else mention this problem, so maybe my sysadmin and I are just stupid, but we can't make getty do the right thing. Given a DN320, bsd environment, and an /etc/ttys line that says tty01 "/etc/getty std.19200" vt200 on I would expect to be able to hang a vt200 on sio port 1 and have it work (with equivalent hardware, the equivalent siomonit command has the desired effect). It doesn't. The port (as dispayed by tctl and demonstrated by its echoing of ~ for a carriage return) doesn't get set to the correct speed, and after setting it to the correct speed, it doesn't issue a prompt. ps shows the getty running, but it doesn't seem to do anything. Anybody recognize this and/or have any helpful suggestions? Getting new hardware is, unfortunately, not an option, and I'm not convinced that's the problem anyway. Larry Setlow pjt@cpac.washington.edu
krowitz@RICHTER.MIT.EDU (David Krowitz) (10/03/90)
/dev/ttyXX devices are tricky. If you use /com/tctl to look at the line settings, you'll find that the settings look something like this: $ tctl -line 1 Status of Line 1: Erase (character delete) character: 08 (hex) Kill (line delete) character: 18 (hex) End of file character: 1A (hex) Quit character: 03 (hex) Fault character: 1D (hex) Suspend character: 10 (hex) New line delay: 0 Speed: 9600 Raw: FALSE, Echo: TRUE, Cvt_NL: FALSE CvtRaw_NL: FALSE, Host_Sync: TRUE, Input_Sync: FALSE RTS: TRUE, DTR: TRUE, DCD: TRUE CTS: TRUE, Quit_Enable: FALSE, Fault_Enable: FALSE Susp_Enable: FALSE, DCD_Enable: FALSE, CTS_enable: FALSE BP_Enable: FALSE, RTS_Enable: FALSE Eight bits per character, Parity: None, One stop bit Errors enabled: FRAMING Polite: FALSE, Wait for DCD: TRUE, Notice that "Wait for DCD: TRUE"? It means that the line will refuse to respond to incoming characters until it sees the Data Carrier Detect line set. This is a pin that is not wired in most null modem cables used for simple dumb terminals. In the example above, DCD is TRUE because I actually have a modem (well, in truth, an IDSN telephone's data port) connected to my RS232 port will a full modem cable. Most terminal cables are either wired for XON/XOFF handshaking with the following: pin1 -- pin1 frame ground pin2 -- pin3 transmit/receive pin3 -- pin2 receive/transmit pin7 -- pin7 signal ground or they are wired for CTS/RTS handshaking with the following: pin1 -- pin1 frame ground pin2 -- pin3 transmit/receive (I may have the tran/rcv reversed?) pin3 -- pin2 receive/transmit pin6 -- pin20 clear-to-send/data-terminal-ready pin7 -- pin7 signal ground pin20 -- pin6 data-terminal-ready/clear-to-send Pin 4 may also be jumpered locally to pin 6 on both ends so that both clear-to-send (CTS) and request-to-send (RTS) will be active. I think DCD is pin 8. I could well be wrong. Different manufacturer's manual's sometimes yield a different set of names. At any rate, you need to jumper the DCD pin to something which is TRUE (DTR is a good one) in order to use /dev/ttyXX. On the other hand, you can use /dev/sioX instead of /dev/tty0X. Even though they both refer to the same S RS232 line, the /dev/sioX device ignores the DCD line state while the /dev/tty0X device handshakes on it. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
rees@pisa.ifs.umich.edu (Jim Rees) (10/03/90)
In article <9010031349.AA05275@richter.mit.edu>, krowitz@RICHTER.MIT.EDU (David Krowitz) writes: Most terminal cables are either wired for XON/XOFF handshaking with the following: pin1 -- pin1 frame ground pin2 -- pin3 transmit/receive pin3 -- pin2 receive/transmit pin7 -- pin7 signal ground If you wire your cable this way, you lose the handshaking signals (the ones that log you out when you hang up the phone, and hang up the phone when you log out). Pins 8 (DCD) and 20 (DTR) are the important ones. So for a straight cable, to go from a computer to a modem, we have 2 -- 2 3 -- 3 7 -- 7 8 -- 8 20 -- 20 and for a null modem cable, to go from a computer to a terminal, 2 -- 3 3 -- 2 7 -- 7 8 -- 20 20 -- 8 I've never used RTS/CTS handshaking, so I always wire 4 to 5 at each end: 4 - - 4 | | 5 - - 5 You could carry these signals through, but I've run across plenty of cases where one end requires CTS and the other doesn't provide it, so it's safer just to jumper them on each end unless you're connecting something (like a printer) that requires these signals actually work. Notice I didn't connect the frame grounds (pin 1). In my opinion, these should never be connected. If you connect them you may get ground loops.
nazgul@alphalpha.com (Kee Hinckley) (10/04/90)
In article <PJT.90Oct2110103@dharma.cpac.washington.edu> pjt@cpac.washington.edu (Larry Setlow) writes: >I haven't seen anybody else mention this problem, so maybe my sysadmin >and I are just stupid, but we can't make getty do the right thing. >Given a DN320, bsd environment, and an /etc/ttys line that says > >tty01 "/etc/getty std.19200" vt200 on tty's only wake up on carrier. Change it to sio1 and it ought to work. (How is this supposed to work on "real" Unix?) -- Alphalpha Software, Inc. | motif-request@alphalpha.com nazgul@alphalpha.com |----------------------------------- 617/646-7703 (voice/fax) | Proline BBS: 617/641-3722 I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.