home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / sysv386 / 12253 < prev    next >
Encoding:
Text File  |  1992-07-22  |  3.5 KB  |  78 lines

  1. Newsgroups: comp.unix.sysv386
  2. Path: sparky!uunet!wupost!sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!news.unomaha.edu!odin!winslade
  3. From: winslade@odin.unomaha.edu (John Winslade)
  4. Subject: Fun with uugetty (ISC)
  5. Message-ID: <winslade.711825566@odin>
  6. Summary: respawns
  7. Keywords: uugetty
  8. Sender: news@news.unomaha.edu (UNO Network News Server)
  9. Organization: University of Nebraska at Omaha
  10. Date: Wed, 22 Jul 1992 17:19:26 GMT
  11. Lines: 65
  12.  
  13. First of all, thanks to all who responded to my early plea for help regarding
  14. the inability to operate a line bidirectionally under ISC 2.whatever.  I'll
  15. summarize briefly a couple of the conclusions.
  16.  
  17. 1. The uugetty that is shipped with the BNU package from ISC does not work
  18.    properly, in that it will not step aside and allow another process to 
  19.    access the line in an outbound direction.  My test program, which opens
  20.    dev/ttyd00, while uugetty (WITH the -r option) is monitoring the
  21.    (without the 'd') /dev/tty00 line, will fail on the open.
  22.  
  23.    Substituting the new uugetty 2.0 will allow this.  The test program
  24.    opens the line, writes a few chars to the modem, closes the line, and
  25.    the uugetty steps back in and re-inits the modem and waits.
  26.  
  27. 2. Several people recommended the FAS driver.  I've obtained it, but have not
  28.    installed it yet, since I want to get up a bit on the learning curve
  29.    and also try to get the stock driver to work as it should.  With the
  30.    stock driver and new uugetty, it does appear that bidirectional access
  31.    will work.
  32.  
  33. There are, however, two remaining problems, and I am hoping somebody has
  34. already pulled hair over these and can prevent any more pulling of mine. ;-)
  35.  
  36. First is an unpredictable respawn of the uugetty at seemingly random times.
  37. It will work for a while, then respawn several times, each with a re-init
  38. of the modem, and finally (init I think) warns that it is respawning too
  39. quickly and locks it out.  Doing an init q will (usually) bring it back up
  40. for a while.
  41.  
  42. I've enabled max debugging and watched what comes out.  The modem init is
  43. fine, and the getty process blocks at the read call (as it should) when it
  44. waits for a character from the line.  It never logs that it got a character
  45. (unless it really does, like when I call in) but respawns from that point.
  46.  
  47. The way I understand Unix, one of two things must happen in order to
  48. terminate the read call, either a successful read, in which case the read
  49. call will return normally, or a signal, in which case if no handler or
  50. action is defined, the process will terminate.  My next step (unless
  51. somebody has a better idea ;-) will be to try to trap and log signals,
  52. perhaps even doing the dreded longjmp() back just before the read call
  53. as a workaround until I figure out what is really going on.
  54.  
  55. Second, <very nasty profanity deleted> I STILL cannot get cu to let me
  56. to access the line.  I've defined /dev/tty00 as major 3, minor 16 (with
  57. rlsd control) and /dev/ttyd00 as major 3 and minor 0.  A quickie test
  58. program can open /dev/ttyd00 and write data to the modem whether or not
  59. the new uugetty is running.  I've also got a DIR entry for ttyd00 in the
  60. Devices file.  Each attempt of
  61.  
  62. cu -l ttyd00            or
  63. cu -l /dev/ttyd00
  64.  
  65. results in NO DEVICES AVAILABLE (yes, all caps) displayed.
  66.  
  67. I'm sure I must be overlooking something simple or stupid.  I've read
  68. every TFM I can find with nothing really explicit on how to troubleshoot
  69. something like this.
  70.  
  71. As before, any and all advice appreciated.
  72.  
  73. Thanks    Good day       JSW
  74.  
  75. winslade@odin.unomaha.edu      <---- best
  76. jsw@drbbs.omahug.org
  77.  
  78.