Project

General

Profile

Actions

Bug #2014

closed

Possible autofp issue in detection causing extended runtime processing a pcap.

Added by Jason Ish about 7 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Affected Versions:
Effort:
Difficulty:
Label:

Description

This issue was found while working on the Rust DNS parser before handling lost responses, but also occurs in git master by disabling the line of code that marks transactions as having their reply lost, so they are never marked complete.

diff --git a/src/app-layer-dns-common.c b/src/app-layer-dns-common.c
index 3eb507adb..56b5c4ebe 100644
--- a/src/app-layer-dns-common.c
+++ b/src/app-layer-dns-common.c
@@ -394,7 +394,7 @@ DNSTransaction *DNSTransactionFindByTxId(const DNSState *dns_state, const uint16
                 return tx;
             } else if ((dns_state->transaction_max - tx->tx_num) >
                 (dns_state->window - 1U)) {
-                tx->reply_lost = 1;
+                //tx->reply_lost = 1;
             }
         }
     }

Note: I still need to extract a data set to make this happen.

What happens in Suricata will run but will get in a state where one thread is using 100% CPU and the rest are idle. perf shows a lot of time spent in DeStateSignatureAppend.

More details to come.


Files

perf-report.png (181 KB) perf-report.png Jason Ish, 02/02/2017 03:59 PM
Actions #1

Updated by Jason Ish about 7 years ago

  • Subject changed from Possible autofp issue in detection. to Possible autofp issue in detection causing extended runtime processing a pcap.
Actions #3

Updated by Victor Julien about 7 years ago

  • Description updated (diff)
Actions #4

Updated by Andreas Herz almost 7 years ago

  • Assignee set to OISF Dev
  • Target version set to TBD
Actions #5

Updated by Peter Manev almost 7 years ago

@Jason Ish - Could it be related to -
https://redmine.openinfosecfoundation.org/issues/2101
? (which was fixed)

Actions #6

Updated by Victor Julien almost 7 years ago

No this is a different issue.

Actions #7

Updated by Victor Julien about 5 years ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Jason Ish
  • Target version changed from TBD to 70

Is this still current?

Actions #8

Updated by Jason Ish about 5 years ago

In the C code, if I make the same adjustment above, yes it still does happen. This is more or less simulating reply losses.

The Rust code does not exhibit this behaviour as it does not match up requests and responses. We can probably mark this as closed as we're planning to remove the C based DNS parser.

Actions #9

Updated by Victor Julien about 5 years ago

Can you describe and share your test case? In my testing I'm not seeing significant differences between commenting out that line and not.

Actions #10

Updated by Victor Julien over 4 years ago

  • Status changed from Assigned to Closed
  • Assignee deleted (Jason Ish)
  • Target version deleted (70)

Closing as from 5.0 on we only have the Rust implementation.

Actions

Also available in: Atom PDF