New flow does not ever get to ESTABLISHED state

Help
1

We’re seeing some odd behaviour with suricata and smb (and maybe other TCP based app protocols in general). Basically, if an existing flow times out, and a new flow is created, the new flow would never enter established state.

In this case, the ssn->state never advances, as there are no more tcp handshakes going on. But obviously the tcp connection is active with packets from both ends. This seems to bypass some rules that checks for the established state. Can someone please advise if this is working as expected or a bug?

    if (f->flow_state == FLOW_STATE_ESTABLISHED) {
        SCLogDebug("pkt %p FLOW_PKT_ESTABLISHED", p);
        p->flowflags |= FLOW_PKT_ESTABLISHED;

    } else if (f->proto == IPPROTO_TCP) {
        TcpSession *ssn = (TcpSession *)f->protoctx;
        if (ssn != NULL && ssn->state >= TCP_ESTABLISHED) {
            p->flowflags |= FLOW_PKT_ESTABLISHED;
        }
    } else if ((f->flags & (FLOW_TO_DST_SEEN|FLOW_TO_SRC_SEEN)) ==
            (FLOW_TO_DST_SEEN|FLOW_TO_SRC_SEEN)) {
        SCLogDebug("pkt %p FLOW_PKT_ESTABLISHED", p);
        p->flowflags |= FLOW_PKT_ESTABLISHED;

        FlowUpdateState(f, FLOW_STATE_ESTABLISHED);
    }
2

I found the answer to my own question.
There is a setting in the stream-engine to pick up mid-stream tcp sessions. See
documentation

I don’t know why suricata has this default to false though given that there are settings for the flow timeouts and almost always we’ll end up with some alive TCP sessions being dropped as flows due to inactivity, but these could revive as activity picks up again.

For smb, the default timeout is 15mins, I don’t think we’d want to have a generic tcp flow timeout that long, which means, for smb, you’ll almost always end up with a broken flow after the flow timeout and smb resumes activity.