-
Andrew Vagin authored
Currently the kernel doesn't report sequence numbers for contracks and tries to restore them from first packets. When we are restoring a tcp connection, we send a window probe and set seq - 1 in it to get ack immediatly. /* Use a previous sequence. This should cause the other * end to send an ack. Don't queue or clone SKB, just * send it. */ tcp_init_nondata_skb(skb, tp->snd_una - !urgent, TCPHDR_ACK); But conntrack doesn't like this, because then we get ack, which is greater than seq. It looks like we try to ack data which we haven't received yet. [ 735.528073] td_maxwin == 0 seq=1081132048 ack=2965916432+(0) sack=2965916432+(0) win=342 end=1081132048 tcp_in_window: sender end=0 maxend=0 maxwin=0 scale=0 receiver end=0 maxend=0 maxwin=0 scale=0 [ 735.533409] log_invalid: seq=2965916431 ack=1081132049+(0) sack=1081132049+(0) win=342 end=2965916431 tcp_in_window: sender end=2965916431 maxend=2965916773 maxwin=342 scale=0 receiver end=1081132048 maxend=1081132390 maxwin=342 scale=0 [ 735.537651] nf_ct_tcp: ACK is over the upper bound (ACKed data not seen yet) The kernel sets IP_CT_TCP_FLAG_BE_LIBERAL for new conntracks, if we are in the middle of a connection. Signed-off-by:
Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com>
afde3659