From: gerg@netcom.com (Greg Andrews)
Subject: Re: uucp woes
Summary: The packet was good, but the computer rejected it.
Keywords: uucp esix worldblazer sas
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Mon, 4 Jan 1993 08:18:29 GMT

jeff@wisdom.bubble.org (Jeff Ross) writes:
>
>here is the saga, running (or trying to run) Esix SVR4 (4.0.4) however I am
>plaiged by problems with uucico and/or SAS-1.25.  To make matters worse
>there is a telebit worldblazer (LA7.01 roms problems where present with
>5.01 as well)
>
>when I call out from the Esix machine and download files from a remote
>host the transfer will fail, no if ands or buts about it, all I get 
>are alarms, the alarms will come at random times durring the transfer,
>but always within the first 40k or so.
>
>after borrowing an hp datascope from work, I monitored the line between
>the modem and computer sent it to telebit for evaluation, their
>assesment was that the worldblazer was functioning properly and that the
>unix machine was not, more specifically, the unix machine was
>"supposedly" dropping a packet and requesting a retransmission which the
>worldblazer "supposedly" retransmitted correctly.  according to telebit
>they even examined the packets that the telebit was sending to the
>unix machine to verify the checksum was correct. (it was) thus they
>concluded that the worldblazer is fine, but the unix machine is at
>fault.
>

Jeff, what other conclusion can be drawn?  Your analyzer trace showed
the bytes that the WorldBlazer and your ESIX system exchanged.  It logged
everything the WB sent to the computer.  That trace showed a perfect
transfer up to the failure point.  Suddenly, the ESIX uucico started 
rejecting a packet from the WB.  Examination of that packet shows:

	o The packet had the correct sequence number (0) and carried
	  the correct ack for the data packet last sent by the ESIX
	  uucico (2).

	o The packet passed the header XOR check.

	o The packet had the correct number of data bytes (64).
	  I.e., the packet delivered by the modem didn't have any
	  extra characters or missing ones.

	o The packet passed the data checksum test.

	o There were no extra characters between packets that could
	  have confused uucico.


The trace shows that the modem placed a correctly formed data packet onto
the RS232 cable, but uucico rejected it (paused for several seconds, then
acked the previous packet number).  The modem re-sent that same packet
10 times until uucico abandoned the transfer.

If the WB sent a good packet but uucico rejected it, how can any other
conclusion be drawn but the WB worked correctly and uucico didn't?


Tech support's statement that your computer was dropping bytes is just
a theory.  (How do I know that?  That theory originated with me.)  There's
no way to look at a trace from the RS232 cable and know what happened to
the data after it entered the computer.

That theory (dropping bytes) isn't airtight.  Usually a packet corrupted
by dropped bytes will be accepted on the first retransmission.  This one
was rejected every time.  Bytes would have to be dropped EVERY time the
packet is re-sent, and that's very rare.  Plus, that kind of problem
usually manifests itself much sooner in the transfer, especially if it's
bad enough to occur within the first 70 bytes of the data burst (each
retransmission started with the rejected packet).

Why did I suggest the computer was dropping bytes?  That's the most common
cause of rejected packets on spoofed uucp transfers.  The only other
theories I have are in areas outside my expertise - for example, something
is munging the variable that holds the packet number your uucico is
expecting to receive.  It gets a correct packet, but thinks the sequence
number is wrong, so rejects it.  Another variable holds the packet number
of the last correctly received packet, and that variable isn't munged, so
the NAK looks normal.  (actually, it's an ACK for the previous packet)


I can't explain the success of the transfers with the T2500 and direct
connections except to say the pattern of data flow will be different
from a WB, and that difference might be uncovering a problem in the
computer.  The analyzer trace shows that the WB sent out a good packet
and the computer rejected it.  The problem isn't in the WB.

-- 
:::::::::::::::::::  Greg Andrews  gerg@netcom.com  :::::::::::::::::::
ObGuindon:  Henry Schultz is worried.  He's found a slip of paper
            in his pocket which says he has been passed by inspector
            number 7.  He figures they did it while he was asleep.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Xref: sparky comp.unix.sys5.r4:1137 comp.unix.programmer:5841 comp.unix.misc:4845