stream: improve 3whs completed by ACK with data

If the ACK packet completing the 3whs is received, the stream engine will
transition to "established". However, the packet itself will not be tagged
as "established". This will only happen for the next packet after the 3whs,
so that `flow:established` only matches after the 3whs.

It is possible that the ACK packet completing the 3whs was lost. Since the
ACK packets themselves are not acknowledged, there will be no retransmission
of them. Instead, the next packet can have the expected ACK flag as well as
data.

This case was mishandled in a subtle way. The stream engine state transition
was done correctly, as well as the data handling and app-layer updates.
However, the packet itself was not tagged as "established", which meant
that `flow:established` would not yet match.

This patch detects this case and tags the packet as established if ACK
with data is received that completes the 3whs.

Bug: #7264.

diff --git a/src/stream-tcp.c b/src/stream-tcp.c
index b212f1e991646592f010e680d3c8dcc92e6f5751..1ae7c013ae12a5b3d3f1ac511d09afb999c2741f 100644 (file)
--- a/src/stream-tcp.c
+++ b/src/stream-tcp.c
@@ -2520,6 +2520,14 @@ static int StreamTcpPacketStateSynRecv(
             StreamTcpPacketSetState(p, ssn, TCP_ESTABLISHED);
             SCLogDebug("ssn %p: =~ ssn state is now TCP_ESTABLISHED", ssn);
 
+            /* special case: normally the packet following the 3whs is
+             * considered flow established, but with data we need it to
+             * be established now. This can happen if the original ACK was
+             * lost. */
+            if (p->payload_len) {
+                p->flowflags |= FLOW_PKT_ESTABLISHED;
+            }
+
             StreamTcpReassembleHandleSegment(tv, stt->ra_ctx, ssn, &ssn->client, p);
 
             /* If asynchronous stream handling is allowed then set the session,