home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / dcom / modems / 12849 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  1.4 KB
  1. Path: sparky!uunet!olivea!hal.com!decwrl!bu.edu!buengc.bu.edu!apollo
  2. From: apollo@buengc.bu.edu (Doug A. Chan)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Intel 400/e bug
  5. Message-ID: <95153@bu.edu>
  6. Date: 2 Sep 92 00:37:13 GMT
  7. Sender: news@bu.edu
  8. Distribution: na
  9. Organization: College of Engineering, Boston University, Boston, MA, USA
  10. Lines: 26
  11. Originator: apollo@buengc.bu.edu
  12.  
  13. I've got a few different brands of modems attached to a Xylogics Annex
  14. terminal server.  Two of which happen to be new Intel 400e (14.4k external
  15. fax/modems)...  Well, I got complaints from some people who tried to
  16. dial into these modems that they would connect but can't do anything else.
  17. After one and a half days of digging (and loss of much hair), I have found
  18. the bug.
  19.  
  20. When the Annex terminal server hangs up a call, it drops DTR and RTS.
  21. If the following is done:
  22.  1) Drop RTS signal
  23.  2) Drop DTR signal (modem should disconnect as usual)
  24.  3) Raise RTS
  25.  4) Raise DTR (allow for next incoming call)
  26. the next caller can connect but will be in limbo.  The modem thinks that
  27. the RTS signal is still low.  However, if the caller hangs up now, the
  28. modem will work normally for the next call.  This has the effect
  29. of making the modem work only for every other call!
  30.  
  31. FYI, the modems' settings were (S0=1 E0 Q1) and DTE is 38.4K.
  32.  
  33. The connect speed, error correction and compression setting have no
  34. effect on the problem.
  35. I'm currently waiting for Intel's response....
  36.  
  37. -Doug
  38. apollo@buengc.bu.edu
  39.