cgwst@unix.cis.pitt.edu (Gray Watson) (01/23/91)
This probably has been hashed before here, but I can't find it in my archives.
I am having problems getting the CLOCAL flag to work with my ESIX V3.2 Rel D.
According to the manual entries, if the CLOCAL flag is *not* set, when the
carrier detect line is dropped by the modem (the remote modem hangs up or the
line is dropped) the tty driver should send a HUP signal to the process group.
I can't get it to work.
I am betting that it is the driver from AT&T that is broke. Have *any* of the
SysV3.2 ports out there fixed this??
Questions:
a) am I right that the V3.2 tty driver does not have this implemented?
If I am wrong then what do I need to do to get it to work.
b) anyone fix the tty driver or have a work around. I have already written
an idle-kill program that resets the line if it determines I've been
idle for X minutes, but it is a hack. I can't run a shell that needs raw
mode (bash,tcsh) and I can't execute a program that needs raw mode . If I
do and I get killed, characters stream to the modem and my idle program
can't tell that I am off.
FYI: I am running on a standard 386/33 with ESIX V3.2 Rel D. My program is
using standard termio sequences. I have tested the DCD line (at the back
of the computer) and it is being asserted correctly.
Thanks for any help.
gray
gray@med.pitt.eduallbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/23/91)
As quoted from <82177@unix.cis.pitt.edu> by cgwst@unix.cis.pitt.edu (Gray Watson): +--------------- | I am having problems getting the CLOCAL flag to work with my ESIX V3.2 Rel D. | According to the manual entries, if the CLOCAL flag is *not* set, when the | carrier detect line is dropped by the modem (the remote modem hangs up or the | line is dropped) the tty driver should send a HUP signal to the process group. | I can't get it to work. | | I am betting that it is the driver from AT&T that is broke. Have *any* of the | SysV3.2 ports out there fixed this?? +--------------- A sucker bet. I have yet to find a System V-like system on which it *doesn't* work, including Xenix (despite SCO's disgusting tty1a/tty1A hack, which is *still* used in SCO UNIX --- I ignore it and use the correct uugetty and Devices "M" subfield with no problems). Your description does, however, indicate the problem --- because it mis-states how CLOCAL works, and thereby indicates a common bit of confusion about modem and stty configuration. A long-ish tutorial on System V modem control follows. Anyone who does *not* want to read it, hit "n" (or ^N, as appropriate) now. New sysadmins might want to save it to a file for future reference. The System V tty driver defaults to "non-CLOCAL" mode. This mode is characterized by two system actions: - if all processes in the process group exit, DTR is dropped by the computer. - if DCD is dropped by the modem, SIGHUP is sent to the process group. This is desirable for dial-in lines, but makes dial-out impossible. As a result, those who want dial-out capability often set CLOCAL on the ports which will be used for dial-out --- thereby losing the two actions, which can be a problem in itself. Others use the standard settings, but the system acts as if CLOCAL were set; this is the result of a modem which has not been configured correctly. What is the "correct" configuration for the modem? It must be set to (1) return the actual DCD status (i.e. do not set the modem to always assert DCD) and (2) drop carrier when DTR is dropped (i.e. do not set the modem to ignore DTR). Since most modems default to always asserting DCD and ignoring DTR so that they will work "out of the box" with stupid computers/comm programs, they will need to be reconfigured (via switches or commands) before they can be used properly with Unix. The reason for CLOCAL is that, if you configure the modem this way, you can't dial out with the default (CLOCAL not set) configuration because the open() on the modem will hang waiting for carrier. So you open the modem with O_NDELAY, perform an ioctl() to set CLOCAL, and clear O_NDELAY. The resulting file descriptor to the modem can be used to dial out. The "M" subfield I mentioned above is BNU (aka HoneyDanBer) UUCP's way of doing this. Look at the comments in /usr/lib/uucp/Dialers for more information --- this is described in the comments for the *second* Dialers entry for "hayes" (which is commented out). Note that if you use this scheme for dial-in/dial-out, you must use "uugetty -r" on the modem, not regular getty. Otherwise, you can get some nasty "chatter" between the modem and getty --- if you are using the internal COM ports and this "chatter" happens, especially on a 9600 baud modem, your system will come to a screeching halt! ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
jde@everex.uucp (-Jeff Ellis()) (01/24/91)
In article <82177@unix.cis.pitt.edu> cgwst@unix.cis.pitt.edu (Gray Watson) writes: >This probably has been hashed before here, but I can't find it in my archives. > >I am having problems getting the CLOCAL flag to work with my ESIX V3.2 Rel D. >According to the manual entries, if the CLOCAL flag is *not* set, when the >carrier detect line is dropped by the modem (the remote modem hangs up or the >line is dropped) the tty driver should send a HUP signal to the process group. >I can't get it to work. > >I am betting that it is the driver from AT&T that is broke. Have *any* of the >SysV3.2 ports out there fixed this?? Have you tried using a port with modem controll? i.e. ttyM00 or ttyM01 with /etc/getty insted of uugetty? This is discribed in TFM Appendix E or the Release notes..... -- Jeff Ellis ESIX SYSTEM/V UUCP:uunet!zardoz!everex!jde US Mail: 1923 St. Andrew Place, Santa Ana, CA 92705
gemini@geminix.in-berlin.de (Uwe Doering) (01/24/91)
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) writes: >The System V tty driver defaults to "non-CLOCAL" mode. This mode is >characterized by two system actions: > >- if all processes in the process group exit, DTR is dropped by the computer. In most SysV tty drivers the assertion of DTR doesn't depend on the CLOCAL flag. It is always raised if at least one process has opened the device, and is dropped if the last process closes the device. This is implementation dependent because the termio(7) man page isn't very clear about what lines belong to the modem control group. Although, the man page clearly states that the HUPCL flag determines whether the DTR line is to be dropped with the last close or not. Therefor, I think controlling the behaviour of DTR with the HUPCL flag instead of CLOCAL is the right thing to do. Uwe -- Uwe Doering | INET : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini
peter@ficc.ferranti.com (Peter da Silva) (01/29/91)
In article <ZOIN42U@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: > In most SysV tty drivers the assertion of DTR doesn't depend on the CLOCAL > flag. It is always raised if at least one process has opened the device, > and is dropped if the last process closes the device. It is also dropped if CLOCAL is clear and the speed is set to B0. Which is lucky, because of the difficulty of re-opening ones control terminal while process group leader... you don't have a control terminal any more and you can't get one because setpgrp fails if you're already process group leader. Gritch. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
gemini@geminix.in-berlin.de (Uwe Doering) (01/30/91)
peter@ficc.ferranti.com (Peter da Silva) writes: >In article <ZOIN42U@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: >> In most SysV tty drivers the assertion of DTR doesn't depend on the CLOCAL >> flag. It is always raised if at least one process has opened the device, >> and is dropped if the last process closes the device. > >It is also dropped if CLOCAL is clear and the speed is set to B0. Which Just to nitpick again :-) : This is implementation dependent, too. If you think of DTR as being independent of the CLOCAL flag (as I stated above), setting the line speed to B0 will drop DTR regardless of the CLOCAL flag. After all, the only purpose of B0 _is_ to drop DTR. Therefor, even in theory, there is no need to link its behaviour to the state of the CLOCAL flag. I admit that there may be drivers out in the real world that work the way Peter described, but you can't rely on it. In FAS, for instance, CLOCAL controls only the carrier detect handling, but not DTR. Yes, I know that FAS isn't the measure of all things. :-) I wonder what the author of the termio(7) man page thinks about these special cases. >is lucky, because of the difficulty of re-opening ones control terminal >while process group leader... you don't have a control terminal any more >and you can't get one because setpgrp fails if you're already process >group leader. Gritch. I agree. The assignment of controlling terminals to processes is rather awkward under SysV. :-( Uwe -- Uwe Doering | INET : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini
peter@ficc.ferranti.com (Peter da Silva) (01/31/91)
In article <VEPNKLP@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: > I wonder what the author of the termio(7) man page thinks about these > special cases. I don't know. I wonder what he thinks about the fact that changing back to B2400 (or whatever) doesn't seem to raise DTR again, but I probably wasn't holding my mouth right. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
mjs@s4mjs.UUCP (M. J. Shannon) (02/10/91)
In article <ZOIN42U@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: )allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) writes: )In most SysV tty drivers the assertion of DTR doesn't depend on the CLOCAL )flag. It is always raised if at least one process has opened the device, )and is dropped if the last process closes the device. ) )This is implementation dependent because the termio(7) man page isn't very )clear about what lines belong to the modem control group. ) )Although, the man page clearly states that the HUPCL flag determines whether )the DTR line is to be dropped with the last close or not. Therefor, I think )controlling the behaviour of DTR with the HUPCL flag instead of CLOCAL is )the right thing to do. The way I always treated it was: HUPCL deals with DTR; CLOCAL deals with CD (in a very different way, of course: CLOCAL on is supposed to mean "ignore the state of the CD signal"). )Uwe Doering | INET : gemini@geminix.in-berlin.de )Berlin |---------------------------------------------------------------- )Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini -- --------------+ <Delapsus Resurgam: When I fall I shall rise. --(10cc)> Marty Shannon | My opinions are just that. You may share them. No one mjs@s4mjs.uucp| speaks for me, and I speak only for myself -- no matter --------------+ where I post from. Get it? Post no flames.