home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / sysv386 / 12362 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  5.6 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!wa4mei!rsj
  2. From: rsj@wa4mei (Randy Jarrett)
  3. Newsgroups: comp.unix.sysv386
  4. Subject: Re: Fun with uugetty (ISC)
  5. Keywords: uugetty
  6. Message-ID: <1992Jul24.031114.27008@wa4mei>
  7. Date: 24 Jul 92 03:11:14 GMT
  8. References: <winslade.711825566@odin>
  9. Organization: Amateur Radio Gateway WA4MEI, Chamblee, GA
  10. Lines: 113
  11.  
  12. In <winslade.711825566@odin> winslade@odin.unomaha.edu (John Winslade) writes:
  13.  
  14. >First of all, thanks to all who responded to my early plea for help regarding
  15. >the inability to operate a line bidirectionally under ISC 2.whatever.  I'll
  16. >summarize briefly a couple of the conclusions.
  17. > 
  18. >1. The uugetty that is shipped with the BNU package from ISC does not work
  19. >   properly, in that it will not step aside and allow another process to 
  20. >   access the line in an outbound direction.  My test program, which opens
  21. >   dev/ttyd00, while uugetty (WITH the -r option) is monitoring the
  22. >   (without the 'd') /dev/tty00 line, will fail on the open.
  23.  
  24. >   Substituting the new uugetty 2.0 will allow this.  The test program
  25. >   opens the line, writes a few chars to the modem, closes the line, and
  26. >   the uugetty steps back in and re-inits the modem and waits.
  27.  
  28. I don't know why they even ship this with the package.  In the docs they 
  29. tell you not to use it but just use /etc/getty. I don't have the release
  30. notes here but there is a section in there that tells about the changes.
  31.  
  32. In your 'Operating System Guide' in the 'Maintenance Procedures' section,
  33. chapter: 'Adding Modems.....', there is a section on Bidirectional 
  34. Capabilities' that will give you all the information you need on what 
  35. devices to use and modem configuration.
  36.  
  37. >2. Several people recommended the FAS driver.  I've obtained it, but have not
  38. >   installed it yet, since I want to get up a bit on the learning curve
  39. >   and also try to get the stock driver to work as it should.  With the
  40. >   stock driver and new uugetty, it does appear that bidirectional access
  41. >   will work.
  42. > 
  43.  
  44. I was using FAS under 2.xx and it was great.  With release 3.0 they 
  45. added in the handlers for the 16550 chips.  You still need FAS if 
  46. you want to use hardware handshaking.
  47.  
  48. >There are, however, two remaining problems, and I am hoping somebody has
  49. >already pulled hair over these and can prevent any more pulling of mine. ;-)
  50.  
  51. >First is an unpredictable respawn of the uugetty at seemingly random times.
  52. >It will work for a while, then respawn several times, each with a re-init
  53. >of the modem, and finally (init I think) warns that it is respawning too
  54. >quickly and locks it out.  Doing an init q will (usually) bring it back up
  55. >for a while.
  56. > 
  57. >I've enabled max debugging and watched what comes out.  The modem init is
  58. >fine, and the getty process blocks at the read call (as it should) when it
  59. >waits for a character from the line.  It never logs that it got a character
  60. >(unless it really does, like when I call in) but respawns from that point.
  61. > 
  62. >The way I understand Unix, one of two things must happen in order to
  63. >terminate the read call, either a successful read, in which case the read
  64. >call will return normally, or a signal, in which case if no handler or
  65. >action is defined, the process will terminate.  My next step (unless
  66. >somebody has a better idea ;-) will be to try to trap and log signals,
  67. >perhaps even doing the dreded longjmp() back just before the read call
  68. >as a workaround until I figure out what is really going on.
  69.  
  70. Get rid of uugetty and your problems should go away.
  71.  
  72. > 
  73. >Second, <very nasty profanity deleted> I STILL cannot get cu to let me
  74. >to access the line.  I've defined /dev/tty00 as major 3, minor 16 (with
  75. >rlsd control) and /dev/ttyd00 as major 3 and minor 0.  A quickie test
  76. >program can open /dev/ttyd00 and write data to the modem whether or not
  77. >the new uugetty is running.  I've also got a DIR entry for ttyd00 in the
  78. >Devices file.  Each attempt of
  79. > 
  80. >cu -l ttyd00            or
  81. >cu -l /dev/ttyd00
  82.  
  83. >results in NO DEVICES AVAILABLE (yes, all caps) displayed.
  84.  
  85. You shouldn't have to do any configuration on the serial devices. When
  86. you build up a and install the a new kernel it will take care of configuring
  87. the devices for you.  I just checked in the dev directory on two different
  88. ISC systems and here and below is what I find. It looks like either 
  89. you have a typing error in your message or you need to change your minor
  90. numbers around.
  91.  
  92. crw-rw-rw-   1 root     root       3, 32 Jul 13 22:59 acu0
  93. crw-rw-rw-   1 root     root       3, 33 Jul 13 22:59 acu1
  94. crw-rw-rw-   1 root     root       3, 34 Jul 23 22:59 acu2
  95. crw-rw-rw-   1 root     root       3, 35 Jul 23 22:59 acu3
  96.  
  97. crw-rw-rw-   1 root     root       3,  0 Jul 13 22:59 tty00
  98. crw-rw-rw-   1 root     root       3,  1 Jul 13 22:59 tty01
  99. crw-rw-rw-   1 root     root       3,  2 Jul 13 22:59 tty02
  100. crw-rw-rw-   1 root     root       3,  3 Jul 13 22:59 tty03
  101.  
  102. crw-rw-rw-   1 root     root       3, 16 Jul 13 22:59 ttyd0
  103. crw-rw-rw-   1 root     root       3, 17 Jul 13 22:59 ttyd1
  104. crw--w--w-   1 root     news       3, 18 Jul 23 18:33 ttyd2
  105. crw--w--w-   1 root     news       3, 19 Jul 23 22:40 ttyd3
  106.  
  107.  
  108. The section of the manual I mentioned above tells you when and how
  109. to use each of the above devices.
  110.  
  111. >I'm sure I must be overlooking something simple or stupid.  I've read
  112. >every TFM I can find with nothing really explicit on how to troubleshoot
  113. >something like this.
  114. > 
  115. >As before, any and all advice appreciated.
  116. > 
  117. >Thanks    Good day       JSW
  118. > 
  119. >winslade@odin.unomaha.edu      <---- best
  120. >jsw@drbbs.omahug.org
  121. -- 
  122. Randy Jarrett  WA4MEI 
  123. UUCP  ...!{emory,gatech}!wa4mei!rsj   | MAIL: 54 Patterson Rd.
  124. PHONE +1 404 822 4073              | Lawrenceville, GA 30244
  125.