From: utzoo!decvax!harpo!seismo!hao!hplabs!sri-unix!milazzo.rice@Rand-Relay
Newsgroups: net.unix-wizards
Title: Re: Dialing In/Out through same port
Article-I.D.: sri-arpa.902
Posted: Wed Mar 30 12:03:35 1983
Received: Tue Apr 19 01:19:03 1983

From:  Paul Milazzo <milazzo.rice@Rand-Relay>

There is a relatively simple method by which a port can be used for
both dial-in and dial-out.  We currently use this method to create
"bidirectional" hardwired and dial-up lines for use with UUCP, MMDF,
and a program called "chat", a locally-written 4.1BSD replacement for
cu.

The basic problem is that a dial-in line has a getty attached which
insists on reading things off the line.  It cannot easily be removed
because init will simply start up another.  The solution we have
adopted works as follows:

 1) Modify /etc/getty to catch a signal such as SIGTERM, and upon
    receipt, to chmod ttyname(0) to 0666, close 0, 1, and 2, and loop
    on a pause().
 2) Create a setuid-to-root program which takes as arguments a terminal
    and signal name, and sends the requested signal to a getty running
    on that terminal (if there is one).  Our original version of this
    program was simply a (terribly slow) setuid shell file, but it has
    since been replaced by a program which browses /dev/kmem.
 3) Modify UUCP, etc., to call this program twice per session; on
    startup send a SIGTERM to make the getty go to sleep, and before
    termination send a SIGKILL to remove the getty.  Init will chmod
    the terminal back to 622 and start up a fresh getty.

Unfortunately, this approach, as outlined, fails for hardwired
connections because after the first use of the line, the two systems
loop trying to log on to each other.  To solve this problem, we added a
set of "quiet" terminal types to getty, which do not print a herald or
"login:" prompt under any circumstances.  This means that users logging
in over a hardwired line must take it on faith to type their userids at
an apparently autistic system (it will of course echo printing
characters).  A better solution would be to define a control character
which does not appear in a herald or logout message, but which will
cause a "quiet" getty to print a "login:" prompt.

This scheme has been in use on Rice's 4.1 systems for about 4 months
now, and most of the flakes have been removed.  We will probably
continue to use it even after the rest of our Ethernet boards arrive.
Still, I am willing to entertain the notion that this is a horribly
incorrect or nonoptimal approach, and encourage comments of all types.

Though this approach is easy to duplicate, we have already written the
code.  If no one points out gigantic flaws, it is free for the asking
(and worth every penny).

				Paul Milazzo,
				Dept. of Mathematical Sciences
				Rice University, Houston, TX