From: winslade@odin.unomaha.edu (John Winslade)
Subject: Fun with uugetty (ISC)
Summary: respawns
Keywords: uugetty
Organization: University of Nebraska at Omaha
Date: Wed, 22 Jul 1992 17:19:26 GMT

First of all, thanks to all who responded to my early plea for help regarding
the inability to operate a line bidirectionally under ISC 2.whatever.  I'll
summarize briefly a couple of the conclusions.
 
1. The uugetty that is shipped with the BNU package from ISC does not work
   properly, in that it will not step aside and allow another process to 
   access the line in an outbound direction.  My test program, which opens
   dev/ttyd00, while uugetty (WITH the -r option) is monitoring the
   (without the 'd') /dev/tty00 line, will fail on the open.

   Substituting the new uugetty 2.0 will allow this.  The test program
   opens the line, writes a few chars to the modem, closes the line, and
   the uugetty steps back in and re-inits the modem and waits.

2. Several people recommended the FAS driver.  I've obtained it, but have not
   installed it yet, since I want to get up a bit on the learning curve
   and also try to get the stock driver to work as it should.  With the
   stock driver and new uugetty, it does appear that bidirectional access
   will work.
 
There are, however, two remaining problems, and I am hoping somebody has
already pulled hair over these and can prevent any more pulling of mine. ;-)

First is an unpredictable respawn of the uugetty at seemingly random times.
It will work for a while, then respawn several times, each with a re-init
of the modem, and finally (init I think) warns that it is respawning too
quickly and locks it out.  Doing an init q will (usually) bring it back up
for a while.
 
I've enabled max debugging and watched what comes out.  The modem init is
fine, and the getty process blocks at the read call (as it should) when it
waits for a character from the line.  It never logs that it got a character
(unless it really does, like when I call in) but respawns from that point.
 
The way I understand Unix, one of two things must happen in order to
terminate the read call, either a successful read, in which case the read
call will return normally, or a signal, in which case if no handler or
action is defined, the process will terminate.  My next step (unless
somebody has a better idea ;-) will be to try to trap and log signals,
perhaps even doing the dreded longjmp() back just before the read call
as a workaround until I figure out what is really going on.
 
Second, <very nasty profanity deleted> I STILL cannot get cu to let me
to access the line.  I've defined /dev/tty00 as major 3, minor 16 (with
rlsd control) and /dev/ttyd00 as major 3 and minor 0.  A quickie test
program can open /dev/ttyd00 and write data to the modem whether or not
the new uugetty is running.  I've also got a DIR entry for ttyd00 in the
Devices file.  Each attempt of
 
cu -l ttyd00            or
cu -l /dev/ttyd00

results in NO DEVICES AVAILABLE (yes, all caps) displayed.

I'm sure I must be overlooking something simple or stupid.  I've read
every TFM I can find with nothing really explicit on how to troubleshoot
something like this.
 
As before, any and all advice appreciated.
 
Thanks    Good day       JSW
 
winslade@odin.unomaha.edu      <---- best
jsw@drbbs.omahug.org