This was a tough one to track down, and also tough to explain...

In cases of packet loss, some broken TCP stacks will send data over the
window of the receiver.  Then, on the next packet they will resend the
missing packet, then move on.  

The current window tracking code 'ignores' this window overage by resetting
the end of the packet to the theoretical maximum (corrects the math of the
stupid sender).

Unfortunately, the sender does receive this over-the-window packet, and does 
increment its ack seq.  So on the next ack after receiving the missing
packet, the receiver acks with the ack seq it knows about, which is higher
than that which the window tracking code thinks it has seen.  Consequently,
it complains that the ACK is over the upper bound, and does not adjust
the window.

After this, communications cease, as each new packet from the sender is
dropped by the window tracking code -- it thinks it is over the window
of the sender.

So, we have seen situations where large ftp transfers stop midstream, but
smaller transfers complete fine (they got lucky).  I've attached a tcpdump
log at the bottom of this message with some annotation and conntrack
debugging inserted in appropriate locations for the interested.

The solution IMO is not to correct the math of the sender -- there is no
benefit to doing so.  The attached patch does this (and also clarifies
the language in some debugging code).

Patrick: this is incremental to the retransmission handling patch you have
already queued up.  Like that patch, I think this should go into 2.6.11.

Phil

Signed-off-by: Phil Oester <kernel@linuxace.com>