home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / unix / sys5 / r4 / 1115 < prev    next >
Encoding:
Internet Message Format  |  1993-01-05  |  4.9 KB
  1. Xref: sparky comp.unix.sys5.r4:1115 comp.dcom.modems:18868
  2. Newsgroups: comp.unix.sys5.r4,comp.dcom.modems
  3. Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!spool.mu.edu!umn.edu!csus.edu!netcom.com!gerg
  4. From: gerg@netcom.com (Greg Andrews)
  5. Subject: Re: uucp woes
  6. Message-ID: <1993Jan4.081829.17615@netcom.com>
  7. Summary: The packet was good, but the computer rejected it.
  8. Keywords: uucp esix worldblazer sas
  9. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  10. References: <1993Jan01.191128.4566@wisdom.bubble.org>
  11. Date: Mon, 4 Jan 1993 08:18:29 GMT
  12. Lines: 90
  13.  
  14. jeff@wisdom.bubble.org (Jeff Ross) writes:
  15. >
  16. >here is the saga, running (or trying to run) Esix SVR4 (4.0.4) however I am
  17. >plaiged by problems with uucico and/or SAS-1.25.  To make matters worse
  18. >there is a telebit worldblazer (LA7.01 roms problems where present with
  19. >5.01 as well)
  20. >
  21. >when I call out from the Esix machine and download files from a remote
  22. >host the transfer will fail, no if ands or buts about it, all I get 
  23. >are alarms, the alarms will come at random times durring the transfer,
  24. >but always within the first 40k or so.
  25. >
  26. >after borrowing an hp datascope from work, I monitored the line between
  27. >the modem and computer sent it to telebit for evaluation, their
  28. >assesment was that the worldblazer was functioning properly and that the
  29. >unix machine was not, more specifically, the unix machine was
  30. >"supposedly" dropping a packet and requesting a retransmission which the
  31. >worldblazer "supposedly" retransmitted correctly.  according to telebit
  32. >they even examined the packets that the telebit was sending to the
  33. >unix machine to verify the checksum was correct. (it was) thus they
  34. >concluded that the worldblazer is fine, but the unix machine is at
  35. >fault.
  36. >
  37.  
  38. Jeff, what other conclusion can be drawn?  Your analyzer trace showed
  39. the bytes that the WorldBlazer and your ESIX system exchanged.  It logged
  40. everything the WB sent to the computer.  That trace showed a perfect
  41. transfer up to the failure point.  Suddenly, the ESIX uucico started 
  42. rejecting a packet from the WB.  Examination of that packet shows:
  43.  
  44.     o The packet had the correct sequence number (0) and carried
  45.       the correct ack for the data packet last sent by the ESIX
  46.       uucico (2).
  47.  
  48.     o The packet passed the header XOR check.
  49.  
  50.     o The packet had the correct number of data bytes (64).
  51.       I.e., the packet delivered by the modem didn't have any
  52.       extra characters or missing ones.
  53.  
  54.     o The packet passed the data checksum test.
  55.  
  56.     o There were no extra characters between packets that could
  57.       have confused uucico.
  58.  
  59.  
  60. The trace shows that the modem placed a correctly formed data packet onto
  61. the RS232 cable, but uucico rejected it (paused for several seconds, then
  62. acked the previous packet number).  The modem re-sent that same packet
  63. 10 times until uucico abandoned the transfer.
  64.  
  65. If the WB sent a good packet but uucico rejected it, how can any other
  66. conclusion be drawn but the WB worked correctly and uucico didn't?
  67.  
  68.  
  69. Tech support's statement that your computer was dropping bytes is just
  70. a theory.  (How do I know that?  That theory originated with me.)  There's
  71. no way to look at a trace from the RS232 cable and know what happened to
  72. the data after it entered the computer.
  73.  
  74. That theory (dropping bytes) isn't airtight.  Usually a packet corrupted
  75. by dropped bytes will be accepted on the first retransmission.  This one
  76. was rejected every time.  Bytes would have to be dropped EVERY time the
  77. packet is re-sent, and that's very rare.  Plus, that kind of problem
  78. usually manifests itself much sooner in the transfer, especially if it's
  79. bad enough to occur within the first 70 bytes of the data burst (each
  80. retransmission started with the rejected packet).
  81.  
  82. Why did I suggest the computer was dropping bytes?  That's the most common
  83. cause of rejected packets on spoofed uucp transfers.  The only other
  84. theories I have are in areas outside my expertise - for example, something
  85. is munging the variable that holds the packet number your uucico is
  86. expecting to receive.  It gets a correct packet, but thinks the sequence
  87. number is wrong, so rejects it.  Another variable holds the packet number
  88. of the last correctly received packet, and that variable isn't munged, so
  89. the NAK looks normal.  (actually, it's an ACK for the previous packet)
  90.  
  91.  
  92. I can't explain the success of the transfers with the T2500 and direct
  93. connections except to say the pattern of data flow will be different
  94. from a WB, and that difference might be uncovering a problem in the
  95. computer.  The analyzer trace shows that the WB sent out a good packet
  96. and the computer rejected it.  The problem isn't in the WB.
  97.  
  98. -- 
  99. :::::::::::::::::::  Greg Andrews  gerg@netcom.com  :::::::::::::::::::
  100. ObGuindon:  Henry Schultz is worried.  He's found a slip of paper
  101.             in his pocket which says he has been passed by inspector
  102.             number 7.  He figures they did it while he was asleep.
  103. :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
  104.