[Oisf-users] Suricata 4.0.0 - bypass/performance issue

[Martin Petracek]

Hi all,
I updated my Suricate from some 2 months old commit to current 4.0.0-rc
and noticed big performance drop.

I'm using suricata with capture bypass, in IPS (NFQUEUE) mode and before
that update haven't seen any slowdown caused by suricata. After this my
connection speed was limited and CPU utilization was high.

Some excerpts from my config:
app-layer:
  protocols:
    tls:
      no-reassemble: yes
stream:
  bypass: yes
  reassembly:
    depth:  1mb


After some digging, I found out that bypass is not working as before and
after bisecting commits between my old version and 4.0.0-rc I came to
conclusion that this is caused by this commit:
https://github.com/inliniac/suricata/commit/26eb49d72130b95a1991484168d263a336c5b19d

I don't fully understand what was the problem that this commit tried to
address, but just by replacing

-        if (ssn->flags & STREAMTCP_FLAG_BYPASS) {
+        if ((ssn->client.flags & STREAMTCP_STREAM_FLAG_NOREASSEMBLY) &&
+            (ssn->server.flags & STREAMTCP_STREAM_FLAG_NOREASSEMBLY))
+        {

in src/stream-tcp.c, I'm having again the performance of the old version.

I guess I might be missing some information as bypass is sometimes
activated too early (as stated in commit description), but I still think
that the performance difference is too big penalty for this.

Oh, I should also mention that I'm using suricata without any rules,
just to perform deep-packet-inspection and get HTTP/TLS/DNS information.
I'm getting these information still, even with this patch. I think the
information drop could be important with some rules.

Isn't the condition in that patch maybe too strict? Or is my use case
just that uncommon?

Thanks!

Regards
Martin Petracek

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20170719/3cee1bc0/attachment.sig>