mrb1@homxc.ATT.COM (M.BAKER) (04/06/89)
Hello ----- Several weeks ago (wow, I guess it's almost a month ago :-) I posted a question about using the Bell Tech HUB6 board on getty-driven UNIX SysV/386/3.2 terminal lines. Specifically, my setup was NOT waggling the DTR & RTS signals when the session ended (via Ctrl-D, or exit, or whatever). Both the AT&T IPC board and the built-in serial port COM1: worked "OK". The problem manifested itself when talking to a RADIAN host port....the machine never released the connection through the PSDN and the LAN port remained "busy" (until you pulled the plug momentarily). Well, I got several nice replies from net-readers as well as a phone call. THANKS to all who offered suggestions, etc. --- and my apologies for this long-delayed summary. At first, I suspected that the Bell Tech board/driver was not handling the B0 (hang-up) c_cflag correctly. But a quick test program in C proved that idea wrong. I think I have finally solved the problem in 3 steps: 1.) We had been using the /etc/inittab entry of ..... /etc/getty tty4foo 9600 for each line. Well our /etc/gettydefs file also contained a set of "H" entries (as in 9600H, 4800H, etc.). They included the 'hupcl' option, along with the substitution of 'sane' for numerous particular flag settings in the normal '9600' entry. getty's ruuning on HUB serial ports now use 9600H instead of 9600 in order to take advantage of the alternate definition (I'll bet it's the hupcl that does it :-) I just didn't want to muck around with changing the '9600' entry which works fine everywhere else). 2.) The HUB6 card lets you refer to its ports two ways: tty4a-tty4f are non-modem controls ports while tty4A-tty4F are modem controls ports. Now logic made me originally choose the "big letters" for my getty entries in /etc/inittab (since we wanted 'modem' controls) but everything works the way I want when I switch to defining my getty with the "little letters". At this point, the line dropped just fine when you enter "exit" command or Ctrl-D to the shell. However, if you connect via the dataswitch and get the login prompt, but then disconnect before entering anything, the getty never died and kept the line "busied-out". The solution here is to: 3.) Add a -t (timeout) option onto the getty entry in /etc/inittab. I used 60 seconds....that seems about right....plenty of time to get that login keyed in, while still saving a long walk to the system in order to jiggle wires and unjam the RADIAN port. Sorry this may be a bit wordy, but I hope it might save someone else a bit of time and trouble if they are ever in this (or a similar situation). Once again, thanks for everyone's help! M. Baker homxc!mrb1