Greetings, We are seeing the following situation, on an established connection: 1: 2049 → 703 [RST, ACK] Seq=1202969688 Ack=1132949130 2: [TCP Port numbers reused] 703 → 2049 [SYN] Seq=1433611541 3: [TCP Out-Of-Order] 703 → 2049 [PSH, ACK] Seq=1132949130 Ack=1202969688 4: 2049 → 703 [RST, ACK] Seq=0 Ack=1433611542 The RST in 4 is dropped, printing out the td_maxack value, it turns out to be: nf_ct_tcp: invalid RST seq:0 td_maxack:1202969688 SRC=10.78.206.110 DST=10.78.202.146 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=43722 DF PROTO=TCP SPT=2049 DPT=703 SEQ=0 ACK=1433611542 WINDOW=0 RES=0x00 ACK RST URGP=0 So basically the SYN in 2 resets the IP_CT_TCP_FLAG_MAXACK_SET, while the out of order frame 3 resets it back, and we end up having again td_maxack=1202969688, that is compared against Seq=0 and the RST is dropped. While we are still testing a proper fix, we would like to have the RST check introduced in [1] tunable. I can send a patch to add a proc bit for that, but I'm wondering whether or not to re-use the tcp_be_liberal option. Please let me know which option would work best for you. Thanks in advance. [1] https://patchwork.ozlabs.org/project/netdev/patch/20090527143523.4649.91602.sendpatchset@x2.localnet/ -- Ali Abdallah | SUSE Linux L3 Engineer GPG fingerprint: 51A0 F4A0 C8CF C98F 842E A9A8 B945 56F8 1C85 D0D5
Attachment:
signature.asc
Description: PGP signature
