Project

General

Profile

Actions

Bug #1411

closed

Suricata generates huge load when nfq_create_queue failed

Added by Andreas Herz about 9 years ago. Updated about 8 years ago.

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

Description

It's a misconfiguration but i guess it should be handled in a better way.
If you have one suricata instance running on QUEUE 0 (with -q 0) or any other process (snort on QUEUE 0 for example) and start another instance of suricata also with -q 0 the following correct error occurs:

<Error> - [ERRCODE: SC_ERR_NFQ_CREATE_QUEUE(72)] - nfq_create_queue failed

But then the second suricata is still processing and starting but generating 100% cpu load (strace shows mass nanosleep).

I would suggest to quit suricata in this error case (easy fix) or implement some sort of mode that periodically checks if the queue is available (kinda complicated) and attaches to the queue, but until then it waits with normal sleep instead of nanosleep.

Actions #1

Updated by Victor Julien about 9 years ago

  • Target version changed from 2.0.8 to 2.0.9
Actions #2

Updated by Victor Julien over 8 years ago

  • Target version changed from 2.0.9 to TBD
Actions #3

Updated by Andreas Herz over 8 years ago

  • Assignee set to Andreas Herz
Actions #4

Updated by Andreas Herz about 8 years ago

That's present with 3.0 as well, any votes against quitting suricata in that case (nfq_create_queue failed)?

Actions #5

Updated by Victor Julien about 8 years ago

I think quitting is fine.

In some other cases, like pcap when the interface is down, we enter a loop to retry opening the iface where sleep inbetween. Perhaps something like this could make sense here?

Actions #6

Updated by Andreas Herz about 8 years ago

Victor Julien wrote:

I think quitting is fine.

I may be wrong but we would quit if we handle the return value correct :)

We start the relevant section with:

int r = NFQInitThread(ntv, (max_pending_packets * NFQ_BURST_FACTOR));

Which results in

return TM_ECODE_FAILED

But we check for r < 0 to quit although TM_ECODE_FAILED is 1. So i would just change it to > 0 or even !=0 since this would be every case unless we get TM_ECODE_OK.
Any objections or did i miss something in my thoughts?

In some other cases, like pcap when the interface is down, we enter a loop to retry opening the iface where sleep inbetween. Perhaps something like this could make sense here?

So you would also suggest waiting for the NFQ to become available again and attach but with a bigger sleep?

Actions #7

Updated by Victor Julien about 8 years ago

Sounds like a simple fix indeed.

Wrt entering a loop, would that be useful you think?

Actions #8

Updated by Andreas Herz about 8 years ago

Well depends on what you want to have, either quit and let the "outside" handle the error or just loop but then is the question when to end and how much resources should be "wasted".
I would prefer the quit since it's some sort of error and you still have to fix it before suricata can work again properly.

I will do a PR with the fixed version and would say we wait until anyone needs the loop solution :)

Actions #9

Updated by Andreas Herz about 8 years ago

  • Status changed from New to Closed
  • Target version changed from TBD to 3.0.1RC1
Actions

Also available in: Atom PDF