[PATCH] TCP window tracking retransmission handling
kadlec at blackhole.kfki.hu
Tue Jan 25 09:33:02 CET 2005
On Mon, 24 Jan 2005, Phil Oester wrote:
> 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).
If we really want to attempt to detect resent packets, then I agree with
you and the proposed solution. I was reluctant to add another field to
ip_ct_tcp, but that cannot be avoided in order to do the job properly.
[However, from another point of view, we actually could get rid of the
feeble attempt of detecting resent packets (and thus the retrans and
last_end fields) with the price of possible dangling connections in the
conntrack table. The current code handles just fine "reopening" stuck
E-mail : kadlec at blackhole.kfki.hu, kadlec at sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
More information about the netfilter-devel