On 23.04.2021 18:26, Florian Westphal wrote: > What is generating this sequence of events? Is #3 just delayed? Yes. > Is this after we let a SYN through while conntrack is still in > established state? Yes. > That would imply #1 was ignored too, else this should have destroyed > the entry. > > Yes, be_liberal is good for this, but nevertheless I'd like to have it > behave correctly out-of-the-box. > > Consider sending a new patch to add a be-liberal check for this. Ok perfect, will send a patch later then. > Problem is that if #1 is ignored, then at #3 we can't easily know if > the syn was bogus (ack is for established connection, still alive) > or if there was re-use (ack is delayed). > Do these problematic connections support tcp timestamps? > If so, we might want to track those so we can check if the segment > is older than what we last saw. > > Only problem is that this increases conn size by 16 bytes, but that > would be acceptable if that solves the problem. Yes, they do support timestamps, but I'm not sure if that will solve the problem, as the problematic out of order frame #5 has more recent timestamps. 1: 703 → 2049 [ACK] Seq=1132947682 Ack=1202969688 Win=2661 Len = 0 TSval=3506781692 TSecr=1717385629 2: 2049 → 703 [RST, ACK] Seq=1202969688 Ack=1132949130 Win=69120 Len=0 TSval=1717385630 TSecr=3506781692 3: 2049 → 703 [ACK] Seq=1202969688 Ack=1132947682 Win=70400 Len=0 TSval=1717385630 TSecr=3506781692 4: 703 → 2049 [SYN] Seq=1433611541 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=3506781693 TSecr=0 5: [PSH, ACK] Seq=1132949130 Ack=1202969688 Win=1362432 Len=604 TSval=3506781693 TSecr=1717385629 6: 2049 → 703 [RST, ACK] Seq=0 Ack=1433611542 Win=0 Len=0 Regards, -- Ali Abdallah | SUSE Linux L3 Engineer GPG fingerprint: 51A0 F4A0 C8CF C98F 842E A9A8 B945 56F8 1C85 D0D5
