acu or acucntrl

[Chris Torek]

In article <230 at vaxine.UUCP> wmp at 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 at umcp-cs		ARPA:	chris at mimsy.umd.edu