mark (03/09/83)
I would like arrange to use our dialout port for dialups as well. Does anyone have any ideas how to accomplish this feat that would work on 4.1bsd? One suggestion I've received requires ther ability to dialout without the Carrier Detect line being high, yet requires the CD line to function normally on dialups. I can't think of a way to do that. Mark Callow Qubix Graphic Systems Inc. ...decvax!decwrl!qubix!msc ...ucbvax!ucscc!qubix!msc
milazzo.rice@Rand-Relay (03/30/83)
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, TXchris.umcp-cs@Udel-Relay (03/31/83)
From: Chris Torek <chris.umcp-cs@Udel-Relay> From: Mark Callow, Qubix Graphic Systems Inc. ...decvax!decwrl!qubix!msc ...ucbvax!ucscc!qubix!msc I would like arrange to use our dialout port for dialups as well. Does anyone have any ideas how to accomplish this feat that would work on 4.1bsd? One suggestion I've received requires ther ability to dialout without the Carrier Detect line being high, yet requires the CD line to function normally on dialups. I can't think of a way to do that. It's not really all that hard. We've got a 4.1 vmunix running right now that does just that. Basically, you need some extra bits for each line: an outgoing flag, and a soft-carrier flag. When checking for carrier you ask, is either the soft carrier or the real carrier on. For dialing out, you set the outgoing flag and the soft carrier, then open the line. When you finally close the outgoing line, you clear the outgoing flag and the soft carrier. For the incoming line, you wait until there is a real carrier and no outgoing flag, then return the opened line. Another change we've made is a "passive" mode. We have two Vaxen hooked together with a cable that connects one end's DTR to the other's CD. For "passive" mode, you DON'T set DTR until you get a carrier; for dial mode, you set DTR and the outgoing flag, as above. Thus either machine can open the dial line to get to the other, where the other just tries to get someone to log in all the time. Yet a third change is a mode which uses the LMDMBUF bit on one end and the DTR line on the other to do high-speed flow control. When one end wants to stop the other, rather than sending ^S, it drops DTR. This makes the other end's CD go off, which in LMDMBUF mode stops that end. We'll send complete details once we're sure everything works right. Currently we've got a bug in passive mode, and the LMDMBUF mode is acting very strange. - Chris
bentson (04/14/83)
I've posted driver diffs and discussion of same in net.sources. The idea is to keep the getty "open" from seeing the carrier of an outward bound connection. Randy Bentson Colo State U - Comp Sci
dave (04/19/83)
There's an even simpler way, though slightly grungier, than what Paul Milazzo suggests. Simply have a program which edits /etc/ttys, and sets the entry for the line used both ways to 0 (for dialout) or 1 (for dialin), followed by a "kill -2 1" to reinitialize the existence/nonexistence of getty on that line. When uucp wants to call out, it simply calls this program before it starts (to do away with getty) and calls it again when it's done (to bring getty back). Of course, the program has to be setuid, and you have to make sure two people aren't trying to muck with /etc/ttys at the same time. And you may need to send a stty hup to the line to make the modem hang up.