home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / dcom / telecom / 12648 < prev    next >
Encoding:
Internet Message Format  |  1992-12-25  |  3.5 KB
  1. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!telecom-request
  2. Date: Fri, 25 Dec 92 23:59:24 CST
  3. From: Jack.Winslade@ivgate.omahug.org (Jack Winslade)
  4. Newsgroups: comp.dcom.telecom
  5. Subject: Strange LD Problem With Modems
  6. Reply-To: jack.winslade%drbbs@ivgate.omahug.org
  7. Message-ID: <telecom12.916.7@eecs.nwu.edu>
  8. Organization: DRBBS Technical BBS, Omaha
  9. Sender: Telecom@eecs.nwu.edu
  10. Approved: Telecom@eecs.nwu.edu
  11. X-Submissions-To: telecom@eecs.nwu.edu
  12. X-Administrivia-To: telecom-request@eecs.nwu.edu
  13. X-Telecom-Digest: Volume 12, Issue 916, Message 7 of 11
  14. Lines: 63
  15.  
  16. We feed a site down in Lawrence, KS.  They usually poll once every
  17. evening using dial-1 AT&T.  We had good transfers up until recently.
  18. They bought a new modem, a Supra v.32bis.  It worked fine for a while,
  19. but ...
  20.  
  21. I got a call from him tonight stating that his sessions are being cut
  22. off as if the carrier was dropped after a few minutes.  He forced a
  23. poll while I was watching, and I noticed garbage streaming and the CD
  24. flashing on and off.  I suggested that he change back to the original
  25. modem (a USR Dual, square LEDs) and try the poll again.  He did, and
  26. the session barfed about two minutes into the data transfer.  It was
  27. as if somebody had simply pulled the plug.  I watched this a couple of
  28. times, and BOTH ends showed hangup and failed session.
  29.  
  30. I then had him repeat the poll with Sprint, with the same results.
  31.  
  32. I then forced a call to him.  The session went perfectly.  Several
  33. batches, about 1.5 megs total.  I was using AT&T.
  34.  
  35. Has anyone ever encountered anything like this?  I've seen hundreds of
  36. random failed sessions and idiopathic disconnects, but never those
  37. that were as easily repeatable.
  38.  
  39. We're using a TB Worldblazer with the latest non-fax ROM revision on
  40. this end.  We have a rather new but burned-in #5 ESS <tm> on this end
  41. and, from the sound of the call-waiting clicks on his voice line, it
  42. appears that he has a #1 or #1A ESS <tm> in Lawrence.  He's noticed
  43. this on both the Supra and the USR.  (The Supra is definitely bad, and
  44. is going back.)
  45.  
  46. It amazes me that the sessions are totally clean one way, but
  47. regularly and repeatedly disconnect the other way.  I think we've
  48. shown that it is not the modem on his end or the LD carrier.  Anyone
  49. care to guess?
  50.  
  51.  
  52. Good day.   JSW
  53.  
  54. Ybbat (DRBBS) 8.9 v. 3.14 r.1
  55. DRBBS - Merry Christmas -- Happy Hanukkah  (1:285/666.0)
  56.  
  57.  
  58. [Moderator's Note: Let's use a process of elimination. What is the one
  59. thing in common about all the bad, failed connections?  He originated
  60. the call.  The Supra and the USR modems couldn't change it. Two
  61. different modems: both bad ... doubtful. First on one carrier, then on
  62. another (Sprint): neither carrier able to deal with it ... doubtful.
  63. When you call him, the modem works fine and the carrier handles it
  64. with no problems. Try these things:
  65.  
  66. Call him a few more times. See if it always works okay using various
  67. carriers and even various modems on his end. Have him try to call some
  68. other site on the opposite end of the earth, or at least in some other
  69. part of the Land of Ahs ... still screwing up? Maybe inadvertently
  70. some obscure piece of code in the uucp software went bad; something
  71. that is only used when he originates uucp ... but not when he receives
  72. uucp.  Have him use the phone line normally used to poll to call your
  73. line voice; the two of you can chat for a few minutes and see if the
  74. line is (or gets) trashed out after a few seconds or a couple minutes.
  75. If so, then the problem may be with telco. Keep these tests up until
  76. you find one unique element always present in the bad connections.  PAT] 
  77.  
  78.