Return to BSD News archive
Newsgroups: comp.os.386bsd.misc Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!spool.mu.edu!uwm.edu!linac!att!csn!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.051002.2690@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University, Ogden, UT References: <1872@dcsc.dla.mil> <1993Jul30.000604.28487@fcom.cc.utah.edu> <23ihduINNpre@kralizec.zeta.org.au> Date: Tue, 3 Aug 93 05:10:02 GMT Lines: 132 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). >(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. >(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). >>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. >>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.