Return to BSD News archive
Newsgroups: comp.os.386bsd.misc Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!uunet!pipex!uknet!mcsun!sun4nl!relay.philips.nl!cnplss5.cnps.philips.nl!bashful.isp.cft.philips.nl!rooij From: rooij@bashful.isp.cft.philips.nl (Guido van Rooij) Subject: Re: Using the sio ports with a Modem Message-ID: <1993Aug3.092159.1696@cnplss5.cnps.philips.nl> Sender: news@cnplss5.cnps.philips.nl (USENET News System) Organization: Philips Communications & Processing Services, Eindhoven References: <1872@dcsc.dla.mil> <1993Jul30.000604.28487@fcom.cc.utah.edu> <23ihduINNpre@kralizec.zeta.org.au> <1993Aug3.051002.2690@fcom.cc.utah.edu> Date: Tue, 3 Aug 1993 09:21:59 GMT Lines: 153 terry@cs.weber.edu (A Wizard of Earth C) writes: >In article <23ihduINNpre@kralizec.zeta.org.au> bde@kralizec.zeta.org.au (Bruce Evans) writes: >>>You aren't going to get result codes or command echo (ie: modem input to >>>the computer) unless DCD is asserted >> >>Yes he is, provided he uses cua00 to talk to the modem or changes the >>-clocal to clocal. [sio doesn't handle clocal right for bidirectional >>ports. The best workarounds for now are: >This interferes with the SIGHUP delivery when the modem is told to deliver >signals to the program so that you can software-catch carrier loss as >something other than a read or a write error (assuming that you don't lose >carrier waiting for CTS, in which case you're hung forever). But it and the >setups you suggest might be the correct workaround for now. >This is why you don't want to do them permanently: >>(1) if you use only the dialin ports for dialin: >> keep clocal off always, using something like: >> stty -clocal before starting getty >> periodic stty -clocal in case some crazy user turned clocal on >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. >>(2) if you use only the dialin ports for dialout: >> keep clocal on always, using something like: >> stty clocal before each session >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. >>(3) if you use only the dialout ports for dialout but don't use the >> dialin ports for dialin: >> same as (2) works but is not necessary for initial dialout; >> One of Andrew Chernov's fixes makes it unnecessary for repeated >> dialouts/ >Same as (1). >>(4) if you use the dialin ports for dialin and the dialout ports for >> dialout: >> same as (1). >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 unless you modify the driver to >>>act correctly with the partial open hack... ie: >> >>act INcorrectly and allow the partial open hack? :-) The hack isn't >>really necessary with the bidirectional ports. >The partial open hack is to defeat DCD no present. This is NOT what the >calling unit devices are for. The calling unit devices are to allow you >to have inbound and outbound calling on the same device without requiring >inbound locking (outbound locking is still required) and to avoid the >traditionaal shell-script edit of /etc/ttys and SUID "kill -1 1" to kill >the getty -- which might be an active user instead -- so that it's safe >to dial out. An example of incoming device locks can be seen in SCO's >uugetty implementation. >>> int fdp; >>> int fd; >>> char *port = "/dev/my_serial_port_name_this_week"; >> >>> /* open, ignoring carrier*/ >>> fdp = open( port, O_RDWR | O_NDELAY); >> >>> /* >>> * open again, respecting carrier (carrier is ignored because of tty >>> * flags from last open) >>> */ >>> fd = open( port, O_RDWR); >> >>> close( fdp); >> >>This won't work with sio (or the old com driver, except that the old >>driver faked carrier always being on) because the last open didn't set >>any tty flags (at least you didn't show them being set). I think the >>following simpler variant of it works: >> >> fd = open(port, O_RDWR | O_NONBLOCK); >> fcntl(fd, F_SETFL, 0); >This shouldn't be necessary (the flags and the non-blocking I/O); it never >has been on Sun, Ultrix, or Sony machines (all BSD boxes). The O_RDWR >should be sufficient. Obviously you are using non-blocking I/O to let you >fcntl() the flags on the device do the carrier isn't necessary for blocking >reads (not shown in your code). Again, the partial open hack should be all >that's necessary. You want to coerce the flags pre-open and then set them >after the previous flags have allowed the open to succeed. It has to do >with applying some flags immediately, and queueing others until after the >open has completed. Really, it's not a "partial open hack"; it's a device >flag queueing heirarchy. >>>(Alarm calls and error checking omitted). This code is what should live >>>in cu, uucp, tip, slattach, and freinds of the family. >> >>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. According to me, if a program wants the signal delivery it either sets clocal or makes the line its controlling tty. 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? >>>Many stty flags are only effective for the duration of the open in the >>>stty program. Beware of settings changing back to default but pretending >>>to be set. ... >> >>This is not a problem with the current version of sio. It never sets >>flags back to defaults unless instructed to do so. This may change. >It probably ought to. The templating of devices is important for getting >around a program setting O_EXCL on a device file and it being stuck that >way -- such that only one program can ever have it open. Remember that >close on exec is implied for O_EXCL files/devices even if it is never >explicitly set. > Terry Lambert > terry@icarus.weber.edu >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -Guido