home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.unix.sysv386
- Path: sparky!uunet!wupost!sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!news.unomaha.edu!odin!winslade
- From: winslade@odin.unomaha.edu (John Winslade)
- Subject: Fun with uugetty (ISC)
- Message-ID: <winslade.711825566@odin>
- Summary: respawns
- Keywords: uugetty
- Sender: news@news.unomaha.edu (UNO Network News Server)
- Organization: University of Nebraska at Omaha
- Date: Wed, 22 Jul 1992 17:19:26 GMT
- Lines: 65
-
- 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
-
-