problem with tip (cu)
Steve Lademann
steve at gec-mi-at.co.uk
Thu Sep 25 23:01:17 AEST 1986
In article <26 at sdsu.UUCP> dlong at sdsu.UUCP (Dean Long) writes:
>
> I can't get tip (cu) to work. The problem is that it can't open() the
>tty device.
That's probably because the Carrier Detect (DCD) line from the modem is
not asserted and the terminal line is 'config'ed with modem support.
Symptoms are that the open hangs until timed out.
>This device is used by uucp with no problems. I looked at
>some of the code for uucp. I saw that uucp uses /dev/kmem to to "enable"
>and "disable" the device before attempting an open. To me it looked like
>it was just setting some bits. Is this really necessary?
The code that does the bit twiddling actually *disables* the modem
control by setting a bit in the software carrier array to indicate to
the driver that it should regard Carrier Detect as being permanently
set. You can also do the same thing at 'config' time by setting the
appropriate bit in the 'flags' word for that particular terminal
controller. This code also normally turns off the 'getty' running on
that terminal line using a variety of methods. The one employed by
4.2BSD (what we run here) is to edit /etc/ttys to disable the terminal
line and send a SIGHUP to init to get rid of it. If you don't do this,
then getty can start arguing with uucp and produce all sorts of strange
results! When uucp has done its thing, the whole thing is vice versaed
to enable modem control and restore the getty on the terminal line. I
believe that System V, 4.3BSD and Ultrix 1.2 have (different, of
course) ways of achieving the same results.
Your next question is fairly obvious. "Why naff about disabling modem
control all the time? Why not just either set it or clear it?" The
reason is that quite a lot of us poor lads out here can't afford to
have separate lines for dailin and dialout. Now, for dialin, you *need*
modem control (DCD detection, that is) otherwise, if the line gets
dropped for any reason (e.g. crumby 'phone lines), your system won't
know it's happened and doesn't know to log off the incoming user. On
the other hand, for dialout, you *don't* need modem control, as with
most modern auto-dial modems, you need to talk to the modem even though
DCD is not asserted. The only danger here is that if the line gets
dropped, your software should know what has happened, and act
accordingly. For 'tip' this is fairly obvious; it goes very quiet. For
uucp, it times out.
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, so that was quite easy to
add to tip at an appropriate point in the connect procedure. You may
also choose to write a dialer for your modem if you want it to be
extra slick. On the other hand, you could just talk to the modem
directly. We use both methods. The most frustrating thing to do is to
intercept all the possible exits from tip, and to ensure that 'acu' is
called again to enable getty and modem control. I just wrote a macro
for 'exit' that did it all, and recompiled. (AAaaarrrgghhh!) (Hint:
the first thing the subroutine called by the macro should do is #undef
exit.)
-----------------------------------------------------------------
|Steve Lademann |Phone: 44 727 59292 x326 |
|Marconi Instruments Ltd|UUCP : ...mcvax!ukc!hrc63!miduet!steve |
|St. Albans AL4 0JN |NRS : steve at uk.co.gec-mi-at |
|Herts. UK | |
-----------------------------------------------------------------
|"The views expressed herein do not necessarily reflect"| _____ |
|"those of my employer, and may not even reflect my own"| ( ) |
-----------------------------------------------------------------
More information about the Comp.unix.wizards
mailing list