Xref: utzoo comp.dcom.modems:2707 comp.sys.att:4507 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!wasatch!utah-gr!uplherc!sp7040!obie!wsccs!terry From: terry@wsccs.UUCP (Every system needs one) Newsgroups: comp.dcom.modems,comp.sys.att Subject: Re: MORE 6386 UUCP WOES ... Summary: Modems under Xenix Keywords: cu, Hayes Modem Message-ID: <727@wsccs.UUCP> Date: 12 Oct 88 02:15:14 GMT References: <319@argon.UUCP> <2096@cuuxb.ATT.COM> Lines: 145 In article <2096@cuuxb.ATT.COM>, mmengel@cuuxb.ATT.COM (Marc W. Mengel) writes: > In article <319@argon.UUCP> daveb@argon.UUCP (Dave Berk) writes: > > [ Woes of using a Hayes compatable modem on a Unix box ] > >Can anyone out there shed any light on this problem ? [description of setting DCD to follow remote carrier] [description of modifying L-devices to talk to modems] > >Is it just me or isn't this a fundamental problem with the tty driver ? > > No, its a fundamental problem with some modems -- they don't signal > the host they are connected to that the line was disconnected. You neglect the brunt of the problem: If you don't use a modem-control device, it doesn't matter how you bludgeon it; it's not going to work correctly. Under Xenix, modem control devices are characterized by an uppercase letter in the device name (tty1A instead of tty1a, etc). This is not absoulute, of course: you could name your device /dev/phil, if you wanted to. The general UNIX implementation of modem-control devices is that of setting either bit 6 or 7 of the minor device number. To find out for sure which should be used on your system, check sio(7) in your manual. In general, if the minor device is greater than 64, it's a modem control device. > >How can I ever use it remotely without being paranoid that if the line > >drops I can't log back in unless I physically am there to kill the > >processes associated with the port and reset the modem ? This, unfortunately, is bogus. The modem should be set to reset on the high-to-low transition of DTR. It should also go back on hook. The UNIX stty parameter (set in /etc/gettydefs) to cause a drop of DTR on port close is HUPCL (Hang UP on CLose). In addition, the port should be set -CLOCAL (Connection is LOCAL), thereby enabling the SIGHUP signal to be set to all processes in that process group when a high-to-low transition of DCD (Carrier Detect) occurs. A normal login session: UNIX box is off, Modem is off: Modem can not, of course, answer phone UNIX box is off, modem is on: Modem can "hear" rings, but still can not answer the phone until DTR is asserted. UNIX box on, port is disabled: Since we are using a modem-control port, DTR is not asserted by the computer, since the port has not been opened. UNIX box on, port is enabled: /etc/getty calls open. This raises DTR on the port. Modem can now answer the phone if it rings. Since we are using a modem control port, the open is stuck until DCD (carrier) is asserted by the modem. A process status (ps -eda) at this point will show a getty on tty ?. UNIX on, DTR high, phone rings: Modem answers the phone. Connection occurs. Modem sends "CONNECT" message to the computer. [NB: at this point, if the port is not a Modem] [ control port or if DCD is forced high in ] [ the cable or the modem, the computer will] [ echo an invalid login message at the ] [ modem. Since the modem has not raised ] [ DCD, it thinks it's calling out and you ] [ want to hang up, so it does. This can be] [ avoided by setting the modem up right or ] [ turning off result codes. Turning off ] [ result codes is a bad idea, since it can ] [ keep you from dialing out. ] Modem raises DCD. Open completes (a ps -eda will show a getty on tty## now). The getty puts out the banner message in /etc/gettydefs and says "login:" and calls gets(). [NB: while at this point, a recevied "break" ] [ will cause the baud rate to change, if ] [ this is defined in /etc/gettydefs ] After the user types in something and hits return, getty exec's /bin/login on the string and prompts for a password. A ps -eda will show login on tty## now. All future logon tries during this call will be handled by /bin/login, and it is no longer possible to change the baud rate. [The user uses the machine for a while to the sound of "Jeapordy" 'Thinking music'] one of two things happens: 1) The user logs out 2) The user hangs up or is cut off 1) The user logs out: The port is closed in the act of hanging up and a signal is sent to init. Meanwhile, since the port is closed and -CLOCAL was specified, DTR is dropped to the modem. The modem resets and goes on hook, dropping DCD. Init acts on the signal and runs /etc/getty on the port again. The modem can answer the phone again. The cycle repeats. .... .... .... 2) The user hangs up or is cut off: The modem drops DCD. Since the port is set HUPCL, all processes are killed by a SIGHUP unless they were specifically told to ignore the signal. The shell dies (same as logging out). The port is closed and the modem resets. The init process is sent a signal. .... .... .... This is the intended setup. The one disadvantage is that you can't get back in without calling again. This can be subverted. Instead of logging out, you get to your lowest level shell (the one run by you logging in) and type: exec /bin/login You will get a "login:" again. Hope this answers some recurring questions. | Terry Lambert UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry | | @ Century Software OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'I have an eight user poetic liscence' - me |