*BSD News Article 19182


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.