home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / dcom / modems / 18483 < prev    next >
Encoding:
Text File  |  1992-12-24  |  5.1 KB  |  119 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!psinntp!jpradley!jpr
  3. From: jpr@jpradley.jpr.com (Jean-Pierre Radley)
  4. Subject: Re: Worldblazer not autobauding correctly at 38400
  5. Date: Thu, 24 Dec 1992 23:18:53 GMT
  6. Message-ID: <1992Dec24.231853.22987@jpradley.jpr.com>
  7. References: <1992Dec19.091753.18781@netcom.com> <1992Dec19.104747.8823@clarinet.com> <BzIvEF.E9@wsrcc.com>
  8. Organization: Unix in NYC
  9. Lines: 108
  10.  
  11. In article <BzIvEF.E9@wsrcc.com> wolfgang@wsrcc.com (Wolfgang S. Rupprecht) writes:
  12. >brad@clarinet.com (Brad Templeton) writes:
  13. >>Sorry for making you type such a long message, but I of course have the
  14. >>modem set in &D3 mode, and have always set my modems that way for years.
  15. >>I can't imagine setting a modem any other way and feeling safe.
  16. >>And yes, DTR is definitely dropping, for a full second, before the new
  17. >>getty takes over, and then, as far as I know, nobody is talking to the
  18. >>modem before the call comes in.
  19. >
  20. >On a TB+ I noticed reset problems with exactly the same setup.  I
  21. >wonder how much of the TB code the WB inherited.
  22. >
  23. >Two things that I found helped a lot:
  24. >
  25. >1) configure the kernel to keep DTR low for much more than 1 second.
  26. >   The TB just didn't reset reliably even at 3 seconds.  I finally
  27. >   picked 7 seconds as a good compromised between resetting and dying
  28. >   of boredom on a tip(1) redial.
  29. >
  30. >2) *Never* let anyone use the manual disconnect switch on the modem.
  31. >   This thing causes the DTR reset to be totally ignored.
  32. >
  33. >3) Don't let anyone that doesn't have a trailblazer call in. ;-) My
  34. >   biggest problems were the modem being stuck in PEP mode w.
  35. >   uucp-spoofing on after a uucp call out.  The next call, if it was a
  36. >   plain-jane 2400 baud modem couldn't connect.
  37. >
  38.  
  39. How and where does one reconfigure an SCO kernel to change the DTR
  40. drop-time?
  41.  
  42. Brad's remark about "nobody is talking to the modem before the next call
  43. comes in" make me observe that getty itself talks to the modem, using the
  44. -h flag to a dialer binary, or a hangup chat script.
  45.  
  46.  
  47. Here's a message from biz.sco.general, AKA the SCO mailing list:
  48.  
  49. >Subject: non-answering modem solution
  50. >Message-Id: <1.dond@sco.com>
  51. >Date:     Tue, 5 May 1992 18:26:42 -0400
  52. >Organization: The Santa Cruz Operation, Inc.
  53.  
  54. Here's an easy and little-known solution to a common modem problem.
  55. It took me a long time to solve this one.  Hope it comes in handy
  56. and saves you some of the frustration that this cost me...
  57.  
  58. After I call out on my modem, it no longer answers the phone.
  59.  
  60. KEYWORDS: uucp honeydanber devices ttys xenix unix auto answer reinitialize -hflag dialer uuchat not called acu
  61.  
  62. RELEASE:  SCO XENIX Operating System Release 2.3.0 through 2.3.4
  63.       SCO UNIX System V/386 Release 3.2 Operating System Version 4.0 and
  64.       earlier
  65.       SCO Open Desktop Release 2.0 and earlier
  66.  
  67. PROBLEM:  My modem isn't being reinitialized for dial-in.  Disabling
  68.       and re-enabling the port doesn't help.   The modem must be
  69.       turned off and on before it will answer the phone again.
  70.  
  71. CAUSE:    Whenever getty (or uugetty) is run, it checks the file
  72.       /usr/lib/uucp/Devices to see if the tty port it is running
  73.       on is a modem port.  If it finds the tty device in the Devices
  74.       file, then getty checks to see if a binary dialer or Dialers 
  75.       file entry is being used.  If one of these is found, then getty
  76.       attempts to hang up the modem line and initialize the modem for
  77.       the next caller.  If a binary dialer is specified on the Devices 
  78.       file line, then getty calls that dialer with the "-h" flag.  If 
  79.       a Dialers file entry is specified instead, then getty calls uuchat,
  80.       passing it the "&" line from the Dialers file entry.
  81.  
  82.       getty uses the first entry which it finds in the Devices file.
  83.       The tty device name is "regularized" (i.e. tty1a and tty1A are
  84.       considered equivalent).  This means that if an entry such as:
  85.  
  86.       Direct tty1a - 2400 direct
  87.  
  88.       appears before the ACU entry for the same tty port, such as:
  89.  
  90.       ACU tty1A - 2400 hayes2400 \D
  91.  
  92.       then getty will decide that no binary dialer or Dialers file
  93.       entry is being used - and the modem won't be initialized for
  94.       dial-in.
  95.  
  96.       It is worth mentioning here that the device names in both
  97.       /usr/lib/uucp/Devices and /etc/inittab should not contain
  98.       the "/dev/" prefix.  For example, "tty1A" should be used;
  99.       not "/dev/tty1A".  If the tty device appears as "tty1A" in
  100.       /etc/inittab, and as "/dev/tty1A" in the Devices file, then
  101.       getty will not find it, and will treat the tty device as
  102.       a terminal rather than as a modem.
  103.  
  104. SOLUTION: Make sure that the "ACU" entry for the modem control port
  105.       in /usr/lib/uucp/Devices contains the desired binary dialer
  106.       name or Dialers file entry name and appears before any other
  107.       entries for this port, including any "Direct" entries for the
  108.       port's non-modem control counterpart.  This "ACU" entry ("ACU"
  109.       is the typical label, it could have another label such as
  110.       "RESET") should also specify the correct speed for 
  111.       reinitializing the modem.
  112.  
  113. -
  114. Don Draper        Support Engineer
  115. dond@sco.COM     Modem Technical Feature Specialist
  116. uunet!sco!dond     The Santa Cruz Operation, Inc.
  117. -- 
  118. Jean-Pierre Radley   Unix in NYC   jpr@jpr.com   jpradley!jpr   CIS: 72160.1341
  119.