summaryrefslogtreecommitdiff
path: root/drivers
diff options
context:
space:
mode:
authorJozsef Kadlecsik <kadlec@blackhole.kfki.hu>2008-07-07 15:57:03 +0200
committerGreg Kroah-Hartman <gregkh@suse.de>2008-07-24 09:14:07 -0700
commitea1bb944a0a2f98350648dcc801c64b11fd7c186 (patch)
tree9e40ef227b10dbb05e93bef04a91c09cfd448e70 /drivers
parent3fa6bcb587adefb2ed2391297529cbead8f03e0a (diff)
netfilter: nf_conntrack_tcp: fixing to check the lower bound of valid ACK
Upstream commit 84ebe1c: Lost connections was reported by Thomas Bätzler (running 2.6.25 kernel) on the netfilter mailing list (see the thread "Weird nat/conntrack Problem with PASV FTP upload"). He provided tcpdump recordings which helped to find a long lingering bug in conntrack. In TCP connection tracking, checking the lower bound of valid ACK could lead to mark valid packets as INVALID because: - We have got a "higher or equal" inequality, but the test checked the "higher" condition only; fixed. - If the packet contains a SACK option, it could occur that the ACK value was before the left edge of our (S)ACK "window": if a previous packet from the other party intersected the right edge of the window of the receiver, we could move forward the window parameters beyond accepting a valid ack. Therefore in this patch we check the rightmost SACK edge instead of the ACK value in the lower bound of valid (S)ACK test. Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers')
0 files changed, 0 insertions, 0 deletions