wmp@vaxine.UUCP (Wayne Power) (10/07/86)
In article <237@miduet.gec-mi-at.co.uk> (Steve Lademann) writes: > So, to use 'tip' with your dialin/dialout line, you need to add similar > code as that used in uucp. We use Bill Sebok's 'acu' program with uucp > to enable/disable the terminal lines and also to check that a dialout > line is not already busy handling a dialin... Our current versions of uucp and tip use this program or one similar to it. This was picked off the net and installed under the name acucntrl by a hacker who no longer works here. The (explative) guy neglected to put the source in the appropriate place, hence I no longer have it. I would be most grateful if some kind soul would send me the source. --wmp Wayne Power decvax!encore!vaxine!wmp
chris@umcp-cs.UUCP (Chris Torek) (10/08/86)
In article <230@vaxine.UUCP> wmp@vaxine.UUCP (Wayne Power) writes: >Our current versions of uucp and tip use this program [`acu'] or >one similar to it. This was picked off the net and installed under >the name acucntrl by a hacker who no longer works here. Acucntrl is indeed Bill Sebok's program. It is on the 4.3BSD distribution tapes. We use kernel hacks: much simpler, and more reliable. This does require kernel source, alas. I have appended a TeX description of our method. I will post context diffs in the future (after I get around to installing 4.3, and sending UDA50 drivers, and a few hundred other pressing things. Sigh.) \magnification=\magstephalf % 11pt % Fonts. If you are using TeX78, or the new Computer Modern fonts, change % this to cmcsc10. \font\tencsc=amcsc10 % Macros \newif\iftm % true if we have mentioned the trademark \def\Unix{{\tencsc Unix}\iftm\else\footnote{$\dag$}{{\tencsc Unix} is a footnote of AT\&T Bell Laboratories}\global\tmtrue\fi} \def\bsd{{\tencsc 4.3bsd} \Unix} % \tencsc does not look very good on these, so we will use regular fonts. %\def\dec{{\tencsc dec}} %\def\dz{{\tencsc dz11}} % official version %\def\dzz{{\tencsc dz}} % short version, purely for variety %\def\dh{{\tencsc dh11}} \def\dec{{\rm DEC}} \def\dz{{\rm DZ11}} \def\dzz{{\rm DZ}} \def\dh{{\rm DH11}} \chardef\us=`\_ % Layout \parskip=.5\baselineskip plus1pt \footline={\ifnum\pageno=1\hfil\else{\tenrm\hfil Dial Devices for \bsd\hfil\llap{\folio}}\fi} % Here we go... % Header, plus page 1 (save paper) % How about THIS title! Catchy, no? \null \vskip1cm \centerline{Some Notes on the Implementation of Dialout Capabilites} \centerline{for Modem Lines under \bsd} \vskip.5cm \centerline{Chris Torek} \vskip.5cm \centerline{Department of Computer Science} \centerline{University of Maryland} \centerline{College Park, MD 20742} \vskip 2cm % Ok. Now what? % How about this: Modern modems may be used in both `originate' and `answer' modes---that is, they can both call out and answer incoming calls. Traditional \Unix\ systems, however, cannot handle this well; modems have typically been dedicated to one purpose or the other. At the University of Maryland, we have devised a set of kernel modifications that allow modem lines to be used bidirectionally. These present a simple user interface and require none of the error-prone locking protocols that have been used in the past to implement similar functionality. Moreover, using our scheme, site administrators can if they so choose implement accounting for all outgoing calls. Previous systems rendered this difficult at best. % Enough extolling of virtues. Now for some details: As far as user programs are concerned, the only change to the system is the addition of a new set of {\it dial} devices. These devices have a one-to-one correspondence with the {\it tty} lines; they are distinguished by having a different major device number. For example, on one machine we have two Racal-Vadic VA3400\footnote{$\ddag$}{Vadic and VA3400 are no doubt trademarks of someone or another} modems. These appear as {\tt tty04} and {\tt tty05}, and also as {\tt dial04} and {\tt dial05}: {\tt\vskip\parskip\parskip=0pt\obeylines\obeyspaces% crw--w--w- 1 root 1, 4 Dec 3 00:06 /dev/tty04 crw--w--w- 1 root 1, 5 Dec 2 00:27 /dev/tty05 crw-rw-rw- 1 root 41, 4 Dec 2 23:13 /dev/dial04 crw-rw-rw- 1 root 41, 5 Dec 2 23:16 /dev/dial05 } Here major device 1 corresponds to the \dec\ \dz.\footnote{*}{\dec, \dh, and \dz\ are trademarks of Digital Equipment Corporation} Major device 41 is also the \dz, but in `dial out' or `outgoing' mode. When a program opens the normal or `incoming' line, it behaves as such programs always have: If there is a carrier on the line, the open completes normally; if not, the open `hangs'---suspends---waiting for a carrier. When a program opens the `outgoing' line, however, something new occurs. If there is a carrier on the line, that indicates that the device is already in use; and the open is rejected with a `Device busy' error, {\tt EBUSY}. (In previous versions of \Unix\ this was called a `Mount device busy' error.) The open is likewise rejected if the line is already in use outgoing. Indeed, in such cases there is always a carrier, so no additional code is required for this: Only if there is no carrier does the open complete---and it will hang up automatically once a carrier has appeared and then vanished. What happens, then, when a line is in the process of being opened for incoming use when the outgoing call is made? Why, nothing, of course: the incoming open remains suspended until the outgoing call has been completed. Anything else would break existing code. As a bonus, no locking is required; outgoing opens succeed if and only if the line is not in use, and incoming opens remain hung during outgoing calls. % Finally, the nitty-gritty; the details; the real guts of the game. To illustrate how this is accomplished, I shall refer again to the \dz\ driver. We have added two new arrays, and made use of an existing third array: There is now a {\tt dz\us inout} and a {\tt dz\us flags}, both of size {\tt NDZ} and type {\tt char}. The first holds the `outgoing mode' flag for each \dzz\ line. Bit $b$ is set in {\tt dz\us inout[$d\/$]} whenever line $b$ of \dzz\ $d$ has an outgoing open in progress. {\tt dz\us flags} holds a permanent copy of the `flags' parameter from the kernel configuration file. In this case these are the software carrier flags. In the original kernel these were put into the array {\tt dz\us softCAR}---also of size {\tt NDZ}---and never touched. We must save them somewhere as outgoing opens work by temporarily asserting the software carrier. We modified the device open code to return {\tt EBUSY} not only on attempts to open a line in `exclusive use' mode, but also on attempts to open a line in outgoing mode whenever the line is already open in any mode. As usual, the super-user is exempt from this restriction. We also modified the open code to: \item {1)} assert the software carrier on outgoing opens; \item {2)} hang until there is a carrier (or software carrier); \item {3)} hang until the line is not in use outgoing, unless this is the outgoing call itself; and \item {4)} reassert DTR every time the state of the line changes. \noindent Incoming and outgoing opens are distinguished by the `flag' argument to the device open routine. This is always a small nonnegative integer for normal opens; but the outgoing open routine calls the regular open routine with a {\tt flag} of {\tt -1}. The fourth point is important because of a change in the close routine. To ensure that a modem hangs up, it is necessary to drop DTR for at least $1\over2$ second. But modems will generally not answer the phone unless DTR is asserted. So the close routine first drops DTR and maintains it that way for one second, then, if it is an outgoing close, turns off the outgoing mode flag, restores the software carrier, and awakens any hung incoming opens so that they may reassert DTR if necessary. As with the open routine, an outgoing close is distinguished by its {\tt flag} argument. We made one more change to the driver. The modem interrupt code---or in the case of the \dz, the modem poll code, for there are no modem interrupts---now checks both the real carrier and the software carrier. Either will allow the open to complete; but if the real carrier is asserted when the line is open in outgoing mode, the software carrier for that line is cleared. This means that once an outgoing call completes, the line is usable only until the connection is closed: When the carrier goes away, the line will be hung up, just as for a normal incoming open. This allows one to perform call accounting, under the condition that the modem never allows calls to be placed without having first lost carrier; and this is true of most modems. The dial-out program would be set-group-ID to a group that can open the `dial' devices. This program would open the device, dial the number, wait for the call to complete, and then log the call in a file. As long as the program were careful not to let the user set {\tt NOHUP} mode on the line, no further calls could be made, as the file descriptor would be invalidated and the program would be sent a {\tt SIGHUP} signal as soon as the connection were broken. (We actually made another change to the \dzz\ driver. {\tt MDMBUF} mode, wherein carrier transitions act as flow control, now works on \dz s as well as \dh s. This is, however, of limited usefulness, as the \dzz\ modem status is only polled once every second; at 1200 baud, up to 120 characters may be sent after a carrier drop before transmission is suspended, and at 9600 baud, up to 960 characters could conceivably be sent. The lack of a modem interrupt is one of many problems with \dz s, and cannot truly be corrected in software.) % Ok. Summary: These kernel changes have allowed us to make greater use, with more ease, of our existing dialer resources. The automatic locking has eliminated all protocol errors that have plagued other systems in the past. And we even log outgoing calls, though we do not charge for them or otherwise restrict them. % clean up \vskip.5cm \line{\it Acknowledgements\hfil} Credit is due Joe Pallas, Bob Kirby, and Fred Blonder, who worked with me on our original implementation for V6 and 4.1{\tencsc bsd} \Unix. This work was no doubt indirectly supported by several government grants and other misdirected research funds. All the errors in this document, however, should be credited only to myself. \bye -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu