From: rsj@wa4mei (Randy Jarrett)
Newsgroups: comp.unix.sysv386
Subject: Re: Fun with uugetty (ISC)
Keywords: uugetty
Date: 24 Jul 92 03:11:14 GMT
Organization: Amateur Radio Gateway WA4MEI, Chamblee, GA

In <winslade.711825566@odin> winslade@odin.unomaha.edu (John Winslade) writes:

>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.

I don't know why they even ship this with the package.  In the docs they 
tell you not to use it but just use /etc/getty. I don't have the release
notes here but there is a section in there that tells about the changes.

In your 'Operating System Guide' in the 'Maintenance Procedures' section,
chapter: 'Adding Modems.....', there is a section on Bidirectional 
Capabilities' that will give you all the information you need on what 
devices to use and modem configuration.

>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.
> 

I was using FAS under 2.xx and it was great.  With release 3.0 they 
added in the handlers for the 16550 chips.  You still need FAS if 
you want to use hardware handshaking.

>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.

Get rid of uugetty and your problems should go away.

> 
>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.

You shouldn't have to do any configuration on the serial devices. When
you build up a and install the a new kernel it will take care of configuring
the devices for you.  I just checked in the dev directory on two different
ISC systems and here and below is what I find. It looks like either 
you have a typing error in your message or you need to change your minor
numbers around.

crw-rw-rw-   1 root     root       3, 32 Jul 13 22:59 acu0
crw-rw-rw-   1 root     root       3, 33 Jul 13 22:59 acu1
crw-rw-rw-   1 root     root       3, 34 Jul 23 22:59 acu2
crw-rw-rw-   1 root     root       3, 35 Jul 23 22:59 acu3

crw-rw-rw-   1 root     root       3,  0 Jul 13 22:59 tty00
crw-rw-rw-   1 root     root       3,  1 Jul 13 22:59 tty01
crw-rw-rw-   1 root     root       3,  2 Jul 13 22:59 tty02
crw-rw-rw-   1 root     root       3,  3 Jul 13 22:59 tty03

crw-rw-rw-   1 root     root       3, 16 Jul 13 22:59 ttyd0
crw-rw-rw-   1 root     root       3, 17 Jul 13 22:59 ttyd1
crw--w--w-   1 root     news       3, 18 Jul 23 18:33 ttyd2
crw--w--w-   1 root     news       3, 19 Jul 23 22:40 ttyd3


The section of the manual I mentioned above tells you when and how
to use each of the above devices.

>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
-- 
Randy Jarrett  WA4MEI 
UUCP  ...!{emory,gatech}!wa4mei!rsj   | MAIL: 54 Patterson Rd.
PHONE +1 404 822 4073		      | Lawrenceville, GA 30244