On Fri, Jul 12, 2019 at 12:50:35PM +0200, Jozsef Kadlecsik wrote:
> On Fri, 12 Jul 2019, Florian Westphal wrote:
>
> > 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@xxxxxxxxxxx>
> > Tested-by: Jakub Jankowski <shasta@xxxxxxxxxxx>
> > Signed-off-by: Florian Westphal <fw@xxxxxxxxx>
>
> Acked-by: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
Applied, thanks for reviewing Jozsef.
