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!utah-morgan!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: <1993Aug5.045537.13166@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> <CB8Aws.H4t@flatlin.ka.sub.org> Date: Thu, 5 Aug 93 04:55:37 GMT Lines: 227 In article <CB8Aws.H4t@flatlin.ka.sub.org> bad@flatlin.ka.sub.org (Christoph Badura) writes: >In <1993Aug3.051002.2690@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: > >>>(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). > >I think you have that backwards. If CLOCAL is clear the driver has to >check the modem control signals. This is true, but I think maybe you have the quote out of order. It's pretty intuitive that a non-local connection would have modem control. If it's not out of order (I'll check back-traffic if it's important to you), then I misspoke. >>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). > >I suppose you mean that the programs don't close the device because >they don't get notified about carrier loss. In any case DTR is only >dropped in response to setting the baud rate to B0 or on last close if >HUPCL is set. I don't see how this possibly interacts with CLOCAL. Actually, I mean programs that drop DTR to reset the modem between multiple calls in a single session. A Credit Bureau Polling System would be one example, where multiple calls may be necessary to get information from TRW, CBI, and TransUnion for a single set of inquiries. The GNUFax software is another example; uucico, a third, and TERM, BLAST, and MLink commercial software examples. >>The partial open hack is to defeat DCD no present. This is NOT what the >>calling unit devices are for. > >IMHO this is exactly what the calling unit devices are for, i.e. to >defeat the partial open hack. This is false. As evidence, the SunOS 4.1.1 System Management manual, which shows the process of rebuilding a kernel after setting the device flags in the config file for SunOS so that the port recognizes modem control at all. If this were true, then one would be *required* to use the calling unit for all out-bound calls. This makes a secure call-back login (such as provided by SVR3/4's "ct" command -- part of BNU [uucp]) nearly impossible to implement on a BSD system. I can't believe that this is intended. In a call-back situation, I log in, eat short-duration charges, and have it call me right back. There are several rationale for wanting to do this; the first is for technical support; a second would be if a business was a member of a "MetroNet" calling program (wherein multiple metropolitan areas are to be considered local calls for the subscriber -- check with US West if you want to buy this) but an employee who lives 40 miles away and works from home is not a "MetroNet" (or equivalent) subscriber (ie: it's a local call for the computer but not for the terminal). A third example might be of a remote printer, where manual dialin and modem connection results in the machine calling back and establishing a print queue on the new connection; There are a large number of Domino's Pizza franchises with a central subscriber dispatch to offer a single number for orders (in California, a 1-800 number) for several metropolitan areas using this method (I know; I helped supply the software). Combined with a "MetroNet" style service at the central office, thousands of dollars a year are saved for ~20 distributed delivery locations, since the connections are nearly always up, and only one "MetroLink" fee needs to be paid instead of ~20. >>The calling unit devices are to allow you >>to have inbound and outbound calling on the same device without requiring >>inbound locking > >This is a side effect of calling unit devices. I should have said "inbound OR outbound" locking. The "inbound" locking is certainly a side effect, but it is an intended side-effect... calling unit devices greatly simplify the issue, since inbound traffic is handled by a single program (getty) and there is not contention for the incoming connections -- only outgoing ones. Actually, this advisory locking is pessimistic thinking, and is not justifiable (more on this later). >>and to avoid the >>traditionaal shell-script edit of /etc/ttys and SUID "kill -1 1" to kill >>the getty > >On which system has this been traditional? Just curious. On SCO and Altos Xenix systems and pre-calling unit BSD releases (4.1C and prior, I believe). The current method on Xenix involves disabling the port using "enable" and "disable" commands. To implement a "user friendly" interface for modem sharing for outbound calls without opening use of the commands to users who may (accidently or maliciously) disable or enable printing. If you look at comp.unix.sources archives (I velive volume 2, but it might be volume 3), you will find programs for "modem sharing" on Ultrix and Sun-3 systems. >>An example of incoming device locks can be seen in SCO's >>uugetty implementation. > >Incoming device locks can be seen in *any* uugetty implementation, >that's what uugetty is for. The SCO uugetty/getty is special in that >it locks *both* the dialin and dialout device (at least in some >implementations). No, uugetty, by original HoneyDanBer design, did *not* do inbound locking; what it did was provide a getty that: 1) Waited for a CR before presenting the initial login banner to avoid "chatter" which could cause the modem to hang up (basically a hole in the modem's state table) when the serial port was incorrectly configured. 2) When the open hung waiting for the DCD completed, it checked the uucp lock file (in /usr/spool/locks -- the pre-HDB version was located in /usr/spool/uucp), and if present, backed off the open and woke up at 10 second intervals and checked if the lock file was valid. The validity of a lock file was checked by killing with signal 0 the PID stored therein -- the functional extension of the kill() interface was released concurrently. I refer you to the O'Reilly publication "Managing UUCP and Usenet". Also look for Tim (O'Reilly's) recommendation in that publication that states you will probably find "TERM" easier to use for async communications (I wrote large portions of the version of "TERM" he refers 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. > >I dont' see what O_EXCL has to do with the "templating" of the >termio(s) parameters. Could you expand on that. If the tty flags are seperated into "modem control" and "non-modem control" chunks, O_EXCL is a non-modem control flag. With a proper implementation, the non-modem-control flags are applied to the device prior to the open completing (otherwise, you would not be able to use O_NDELAY to overcome the lack of DCD -- since O_NDELAY is, technically, not a modem control flag even in its overloaded use here). If I write a program (like uugetty) to intercept incoming connections, I will generally set the O_EXCL flag so that an out-going call will not be able to open the device over top of me, despite advisory locking. In point of fact, uugetty need not use nor observe advisory locking because of this, and, if implemented correctly in all cases, need not back off, since the O_EXCL open() to intercept incoming calls will be blocked by virtue of the O_EXCL being blocked from being applied and the process doing the applying put to sleep until the reference count is decremeted to zero. The HDB reasoning was that the O_EXCL was not correctly implemented in some instances, being driver dependent (the rationale is covered under "smart cards", immediately following). Thus advisory locking is only required in the call-out case, and then only if the exclusivity of the lock applies to a single process rather than on a process group basis. The per-process rather than per-process-group exclusivity applies to forked processes because of an error in sys2.c in the fd duplication code as the result of a fork -- basically, 12 lines of code needed to be moved down 46 lines. This was reported to AT&T Tier 3 support in July of 1988 (by me). Device templating is an artifact of prior implementations of tty device; however, even were it not, it would have to be introduced (and, indeed, will have to be introduced in *BSD) to support consistent behaviour between devices that can have "sticky" attributes -- settings which survive the final close -- and those which do not -- smart cards. Smart cards intrinsically require device templating if they download any of the flow control processing to the card. Computone and Control Systems, Inc. pioneered this in commodity UNIX implementations, but it has been available in DEC multiport boards from the early days. If I download functionality from the tty driver to the I/O controller, then I end up with a split driver; essentially, there is an IPC communication to the board; the problem is that if *any* of this functionality is implemented in hardware, it has a post-initialization and reset default state, which means that I either have to implement functionality in the driver to support port resets (a necessary function if baud rate recognition or other niceities are required), which is not supported in the default upper level programs (getty/uugetty/et al), OR I must have default states to which the device is returned (using the final close of the device as an IPC trigger to do the reset). >>Remember that >>close on exec is implied for O_EXCL files/devices even if it is never >>explicitly set. > >Is it? Where is that documented? And more importantly where is that >implemented? Certainly not in any SysV kernel I know. It is documented in sys2.c in the source code for SVR3; the functionality has moved, but persists in SVR4. If necessary, I can dig the reference out of the SVR4.2 sources (or any release up to SVR4.2 ES/MP, if you prefer old code), but you can prove it to yourself with a rather simple program that opens an outbound port O_EXCL, forks, and has the child fail on a write of one byte with EBADF. I realize that the code is insufficient documentation; but then again, it's obvious that no one has supplied good documentation about "the way it is" for many device drivers -- there's no apparent reason why tty drivers should be an exception to this inconvenience. Consider this a partial fulfilment of your documentation request, although certainly not an authoritative one, since I can't guarantee future behaviour. References: "Managing UUCP and Usenet" -- Tim O'Reilly and Associates "sys2.c" (Component of SVR3.2) -- AT&T(*) "uucico -- full sources" (Component of SVR3.2) -- AT&T(*) "uugetty -- full sources" (Component of SVR3.2) -- AT&T(*) "tty.c, tty_subr.c, tty_ttcompat.c, tty_tty.c" -- Sun Microsystems(*) [SunOS 4.1.2] "TERM Communications Software Users Manual" -- Century Software "Technical Aspects of Data Communications" -- McNeeley (Digital Press) "OEM Programmers Guide: Computone 8 port board" -- Computone(*) "Megaport XP Controller Programmers Guide" -- Equinox Systems Inc.(*) "System and Network Administration" p323,328,331 -- Sun Microsystems [PN: 800-3805-10, Rev A, 27 Mar 1990] (*) Not a publically available reference; source licenses left as an exercise for the reader. Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.