Hi Andi,
From: Andi Kleen <ak@xxxxxx>
>
> On Fri, Mar 24, 2000 at 08:12:08AM +0100, Stephen Rothwell wrote:
> > 16:37:07.987900 owl.rsync > elm.1216: . ack 31383222 win 31856
> > <nop,nop,timestamp 528848505 2055387> (DF)
> > 16:37:07.987946 elm.1216 > owl.rsync: R 2680405324:2680405324(0) win 0
> > 16:37:07.989904 elm.1216 > owl.rsync: R 31436798:31436798(0) ack 79735 win
> > 31856 <nop,nop,timestamp 2147827 528836519> (DF)
>
> The second reset is not generated by the Linux TCP/IP stack (we never send
> RSTs with options and windows). It looks like a normal ACK with a few bits
> flipped (?).
>
> The first one is bogus too because it has wrong sequence numbers, but at least
> the rest of the header looks normal.
>
> I would check the ethernet driver/card.
I was not concerned about the resets. I was concerned about the series of
retransmits near the start of the dumps. Basically a packet from elm gets
dropped
and the correct ack comes back (for the packet just before the dropped
one) and then elm retransmits the dropped packet. Owl then acks the last
but one packet that elm thinks it has sent (presumably another one has been
dropped). Owl send some data to elm until the window fills and then no
more progress is made from either end.
elm is sending acks with window 0 but owl persists in trying to send
another segment.
My understanding of TCP is not wonderful, but this doesn't seem correct.
Just to reitterate, owl is running 2.2.14 (with SACK disabled) and elm
is running 2.2.15pre5.
I would be happy to be told that this is a bug in 2.2.14 that is already
fixed.
Cheers,
Stephen Rothwell sfr@xxxxxxxxxxxxx
|