Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!ncoast!allbery From: allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) Newsgroups: comp.unix.sysv386 Subject: Re: Missing SysV tty device driver feature?? Message-ID: <1991Jan23.034042.3368@NCoast.ORG> Date: 23 Jan 91 03:40:42 GMT References: <82177@unix.cis.pitt.edu> Reply-To: allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) Followup-To: comp.unix.sysv386 Organization: North Coast Computer Resources (ncoast) Lines: 68 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