Under certain circumstances (high latency WAN links for instance), ack
packets get stacked up and arrive in bulk.  The current TCP window
tracking code interprets these numerous acks as retransmits, and
if there are >= 3 retransmits sequentially, it resets the timeout on
a conntrack to 5 minutes.

This is trivially reproducible on a high latency link by an 'ls -lR'
on a large-ish tree.  In my test case, 8 ack packets arrived sequentially
at the end of the listing.  While the seq numbers on those packets
were indeed identical (which the current code tests for), they were acking
unique packets, and thus clearly do not qualify as retransmissions.

The problem lies in the fact that the code currently only examines
the seq number of the arriving packet, but does not also look at the
seq number being acked.  The patch below adds this additional check.
Unfortunately, it adds another int32 to ip_ct_tcp, but I could think
of no other fool-proof way of fixing it (short of ripping out the
retransmission test altogether).

Phil

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