A tcp segment reassemble bug in suricata-6.0.3?

Developers
1

version : 6.0.3
code-file: stream-tcp.c
code-func: HandleEstablishedPacketToServer
code-line: 2294

Only the maximum Ack number received + windows size is the maximum acceptable sequence number. However, this processing method ignores the disorder of packet routing, resulting in some packets being discarded by Suricata as exceeding windows processing because of the delayed delivery of ack.

2

Can you provide a pcap?

3

WechatIMG2974
WechatIMG29741920×805 276 KB

the red line ： Maximum ACK packet sequence number received is 2690057392 window is 65535
the blue line: packet 475 , payload len is 1460, seq number is 2690121632
in func HandleEstablishedPacketToServer:
packet 475 seq number + payload len > max ack number + window, so packet 475 was discarded by suricata, may be ack number in packet 476 is right。

4

e80d8434c4f7ddb24cb565010a98baae2a313976_2_1380x578
e80d8434c4f7ddb24cb565010a98baae2a313976_2_1380x5781380×578 358 KB

the red line ： Maximum ACK packet sequence number received is 2690057392 window is 65535
the blue line: packet 475 , payload len is 1460, seq number is 2690121632
in func HandleEstablishedPacketToServer:
packet 475 seq number + payload len > max ack number + window, so packet 475 was discarded by suricata, may be ack number in packet 476 is right。

5

Can you provide the pcap so we can reproduce the issue? (instead of screenshots)