Return to BSD News archive
Newsgroups: comp.os.386bsd.misc Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: Using the sio ports with a Modem Message-ID: <1993Aug3.223714.18384@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University, Ogden, UT References: <23ihduINNpre@kralizec.zeta.org.au> <1993Aug3.051002.2690@fcom.cc.utah.edu> <1993Aug3.092159.1696@cnplss5.cnps.philips.nl> Date: Tue, 3 Aug 93 22:37:14 GMT Lines: 121 In article <1993Aug3.092159.1696@cnplss5.cnps.philips.nl> rooij@bashful.isp.cft.philips.nl (Guido van Rooij) writes: >terry@cs.weber.edu (A Wizard of Earth C) writes: >>You lose modem control signals from the modem, notably carrier loss >>notification, which is necessary to cause slattach to realize it has lost >>the connection and it needs to be reestablished (or PPP, for that matter). > >Why? If clocal is clear, you'll get them anyway. You can also make >the modem line the controlling tty. If CLOCAL is not set, you can't get result codes from the modem without DCD present in the current driver. That's why his suggestions were workarounds. >>Same problem as above, plus if CLOCAL is set always, a line drop (like a >>power failure at your house but not where the computer is) will leave your >>login session active for the next caller. Also, without DCD drop reconized >>(CLOCAL turns this off), the computer won't drop DTR to the modem, causing >>it to reset as if powered off (if the modem is correctly configured). The >>result is that the first caller in sets the baud rate for all subsequent >>callers until a callout (and DTR drop) or a modem reset. Avatek modems, >>Hayes modems, US Robotics modems, and others suffer from this problem. > >Therefore, you should not use the dialin port for dialout. Certainly not with the current drivers (again, I never disputed this as a workaround, only its desirability in a working driver). >>Except CLOCAL should never be set on a dialin port (but you aren't exactly >>saying it should be set anyway). > >Agreed, therefore -CLOCAL should be the default for dialin ports. Or dialout if you expect your software to work correctly and recognize DCD loss (ie: your Xmodem quits when the line is dropped and reconnects instead of sending 10 packets without ACKs and timing out because it's too stupid to see that carrier went away). It's just that it won't work with the current drivers as implemented. >>>Too many places. Given bidirectional ports, these programs can just open >>>the dialout port, then set CLOCAL to whatever is appropriate. > >>*NEVER* set CLOCAL on a modem -- you lose carrier loss notification. The >>only place this is appropriate is for the "ct" command as part of a dialback >>script for security or to save long distance charges. CLOCAL must be set to >>allow the dialout after the hangup without SIGHUP killing the process. > >But if you don't set clocal, how are you gonna talk to the modem? This >requires additional hacks in the driver that are not very beautiful. Exactly right -- but hacks which are in every version of UNIX serial drivers since the idea of allowing dialout on dial-in lines came out. >According to me, if a program wants the signal delivery it either sets >clocal or makes the line its controlling tty. According to the programming manual, you *can't* set CLOCAL (literally meaning "a local connection") and expect to receive signals from non-local events (like DCD on-to-off transition). CLOCAL by definition defeats the modem control. This is the difference between tty1A and tty1a on SCO boxes -- tty1a has CLOCAL set by default and tty1A doesn't. Unsetting CLOCAL generally has the result of the appearance of a soft DCD loss, since you can't query the current DCD level with CLOCAL set and without polling the port (there is an ioctl() to read, but none to wait for a state change). >I think there are 2 views here, I also talked a lot about exactly >this with Bruce and Andrew Chernov. I dont think there is a standard >here: on Suns, you get the SIGHUP by default, but according to Andrew, >on some other systems you don't, thus allowing multiple dialouts >in one session without having to deal with SIGHUP. I am not aware >of any standard in this area. Does anyone know about one? When I rewrote the Sun and SVR3/SVR4 serial code for TERM (a commercial comm product), I handled connection loss *and* supported simultaneous sessions on telnet, rlogin, pty, and serial transports. This was device consumer code, but the principle is the same; there exists a finite state automaton on both sides of the kernel interface, and both sides can determine the current state of the code on the other side of the wall from their own state. You *want* to deal with SIGHUP to ensure timely response to things like a SL/IP or PPP connection going down. Barring other authoritative examples of BSD behaviour, I believe we should take the SunOS and Ultrix behaviours as our model. Agreed that some serial drivers don't support the idea of signal delivery to their first open and have to be set up as the controlling tty. These serial drivers are broken, since signals are to go to the controlling process, and process group need not be predicated on tty (such systems invariably have problems with programs using pty's, such as "screen"). A good example was available at one time as an interim implementation on Sony NeWS workstations (which also claim BSD heritige). Again, calling unit devices simply avoid incoming device locking which would otherwise have to take place in user space code, ala the SCO uugetty. They server no other purpose, nor should they. If you want to extend the functions provided in the serial driver on the basis of bipartite drivers, a much better mechanism to implement is transparent printing. Let me warn you right off the bat the the Computone model is not sufficient to this task, since it does not guarantee atomicity of escape sequences to the device. A "transparent print" device requires that the print device not become active in such a way as to interrupt a user escape sequence of the normal tty device. This means you will have to maintain an emulation automaton in the driver that represents accurately the current state of the connected device, and only unblock printer I/O when the automaton is at the base (zero) state. But please don't try to extend the calling unit paradigm to anything beyond its intended use in avoiding device locking by using the kernel operations for atomicity. Remember also that at some time in the future, this will all have to fall under the "normal behaviour" of an "ldterm" style module in a stackable I/O system, whether it's a Streams implementation, an X-Kernel implementation, or Bill's promised Currents implementation. Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.