Project

General

Profile

Actions

Bug #1682

closed

Suricata 3.0 Endace DAG error

Added by Leif Tishendorf over 8 years ago. Updated almost 8 years ago.

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

Description

Greetings,

I currently have Suricata 3.0 and 2.0.11 on a box with an Endance 9.2x2 card. I can run, and have been running for some time, 2.0.11 with --dag dag0:2. However, with 3.0 I get the following debug errors:

[25498] 28/1/2016 -- 14:08:57 - (tm-modules.c:44) <Debug> (TmModuleDebugList) -- ReceiveErfDag:(nil)
[25498] 28/1/2016 -- 14:08:57 - (tm-modules.c:44) <Debug> (TmModuleDebugList) -- DecodeErfDag:0x5f4e00
[25498] 28/1/2016 -- 14:08:58 - (runmode-erf-dag.c:104) <Debug> (RunModeIdsErfDagAutoFp) -- Entering ... >>
[25498] 28/1/2016 -- 14:08:58 - (util-runmodes.c:201) <Debug> (RunModeSetLiveCaptureAutoFp) -- live_dev dag0:2
[25498] 28/1/2016 -- 14:08:58 - (tm-threads.c:1034) <Debug> (TmThreadCreate) -- creating thread "RxDAGdag0:21"...
[25499] 28/1/2016 -- 14:08:58 - (tm-threads.c:996) <Info> (TmThreadSetupOptions) -- Setting prio 0 for "RxDAGdag0:21" Module to cpu/core 0, thread id 25499
[25499] 28/1/2016 -- 14:08:58 - (tm-threads.c:910) <Debug> (TmThreadSetPrio) -- Nice value set to 0 for thread RxDAGdag0:21
[25499] 28/1/2016 -- 14:08:58 - (source-erf-dag.c:184) <Debug> (ReceiveErfDagThreadInit) -- Entering ... >>
[25499] 28/1/2016 -- 14:08:58 - (source-erf-dag.c:223) <Info> (ReceiveErfDagThreadInit) -- Opening DAG: /dev/dag0 on stream: 2 for processing
[25499] 28/1/2016 -- 14:08:58 - (source-erf-dag.c:227) <Error> (ReceiveErfDagThreadInit) -- [ERRCODE: SC_ERR_ERF_DAG_OPEN_FAILED(163)] - Failed to open DAG: /dev/dag0
[25499] 28/1/2016 -- 14:08:58 - (source-erf-dag.c:229) <Debug> (ReceiveErfDagThreadInit) -- Returning: 1 ... <<
[25498] 28/1/2016 -- 14:08:58 - (runmode-erf-dag.c:121) <Info> (RunModeIdsErfDagAutoFp) -- RunModeIdsDagAutoFp initialised
[25498] 28/1/2016 -- 14:08:58 - (runmode-erf-dag.c:123) <Debug> (RunModeIdsErfDagAutoFp) -- Returning: 0 ... <<
[25498] 28/1/2016 -- 14:08:58 - (tm-threads.c:1988) <Error> (TmThreadWaitOnThreadInit) -- [ERRCODE: SC_ERR_THREAD_INIT(49)] - thread "RxDAGdag0:21" closed on initialization.

This is just the obvious dag related entries, please let me know if more is needed.

Thanks.

Actions #1

Updated by Jason Ish over 8 years ago

  • Subject changed from Suricata 3.0 Endance DAG error to Suricata 3.0 Endace DAG error
  • Status changed from New to Assigned
  • Assignee set to Jason Ish
  • Target version set to 70
Actions #2

Updated by Jason Ish over 8 years ago

It works for me. This does look more like a DAG configuration error than a Suricata issue though.

Is Suricata 3.0 linked against the same version of the DAG libraries that your 2.0.11 build is? Do those libraries (ldconfig may help here).

Is there library Suricata is linked against in sync with the version of the DAG driver loaded?

There is no other application currently listening on dag0:2?

Actions #3

Updated by Leif Tishendorf over 8 years ago

In trying to track down the issue I have re-compiled the Endance libraries and then compiled 2.0.11 and 3.0 against those, all done today.

I can run 2.0.11 with no issue, then swap over to 3.0 and I get the above mentioned errors. Then swap right back to 2.0.11 with no issue.

Actions #4

Updated by Leif Tishendorf over 8 years ago

Figured out the issue.

run-as:
user: suri
group: suri

For some reason with 2.0.11 it can open /dev/dag0, but with 3.0 it can't. If I comment out run-as it works no problem in 3.0.

Actions #5

Updated by Jason Ish about 8 years ago

With run-as set, I get the same behaviour on 2.0.11 and 3.0. That is, it fails until I change the permissions on /dev/dag* to allow write access to the user or group.

So I'm not sure what would allow your 2.0.11 to access /dev/dag* and not allow 3.0 to access /dev/dag*.

Actions #6

Updated by Jason Ish almost 8 years ago

I wonder if we can close this?

Just tested with master and it works fine running as non-root. As the DAG is exposed as a node in /dev, the device nodes have to be setup with permissions that match your run-as settings.

Actions #7

Updated by Leif Tishendorf almost 8 years ago

Sorry, yes this can be closed.

Actions #8

Updated by Jason Ish almost 8 years ago

  • Status changed from Assigned to Closed
Actions #9

Updated by Victor Julien almost 8 years ago

  • Target version deleted (70)
Actions

Also available in: Atom PDF