diff options
| author | Florian Westphal <fw@strlen.de> | 2019-07-12 00:29:05 +0200 |
|---|---|---|
| committer | Pablo Neira Ayuso <pablo@netfilter.org> | 2019-07-16 13:17:02 +0200 |
| commit | 959b69ef57db00cb33e9c4777400ae7183ebddd3 (patch) | |
| tree | 408fe33d807680e71ff3f9ae2b37c66ba64b65a1 /init/do_mounts_md.c | |
| parent | b83329fb473f29d34d85d642e3a3313bb2871fa9 (diff) | |
| download | linux-next-959b69ef57db00cb33e9c4777400ae7183ebddd3.tar.gz | |
netfilter: conntrack: always store window size un-scaled
Jakub Jankowski reported following oddity:
After 3 way handshake completes, timeout of new connection is set to
max_retrans (300s) instead of established (5 days).
shortened excerpt from pcap provided:
25.070622 IP (flags [DF], proto TCP (6), length 52)
10.8.5.4.1025 > 10.8.1.2.80: Flags [S], seq 11, win 64240, [wscale 8]
26.070462 IP (flags [DF], proto TCP (6), length 48)
10.8.1.2.80 > 10.8.5.4.1025: Flags [S.], seq 82, ack 12, win 65535, [wscale 3]
27.070449 IP (flags [DF], proto TCP (6), length 40)
10.8.5.4.1025 > 10.8.1.2.80: Flags [.], ack 83, win 512, length 0
Turns out the last_win is of u16 type, but we store the scaled value:
512 << 8 (== 0x20000) becomes 0 window.
The Fixes tag is not correct, as the bug has existed forever, but
without that change all that this causes might cause is to mistake a
window update (to-nonzero-from-zero) for a retransmit.
Fixes: fbcd253d2448b8 ("netfilter: conntrack: lower timeout to RETRANS seconds if window is 0")
Reported-by: Jakub Jankowski <shasta@toxcorp.com>
Tested-by: Jakub Jankowski <shasta@toxcorp.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Diffstat (limited to 'init/do_mounts_md.c')
0 files changed, 0 insertions, 0 deletions