Project

General

Profile

Actions

Bug #1524

closed

Potential Thread Name issues due to RHEL7 Interface Naming Contentions

Added by Zach Rasmor over 8 years ago. Updated almost 8 years ago.

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

Description

I have begun testing Suricata on RHEL7, on an interface named "enp132s0." The length of this interface name resulted in the following thread names for my 16 threads:

RxPcapenp132s01
RxPcapenp132s02
RxPcapenp132s03
RxPcapenp132s04
RxPcapenp132s05
RxPcapenp132s06
RxPcapenp132s07
RxPcapenp132s08
RxPcapenp132s09
RxPcapenp132s01 <--
RxPcapenp132s01 <--
RxPcapenp132s01 <--
RxPcapenp132s01 <--
RxPcapenp132s01 <--
RxPcapenp132s01 <--
RxPcapenp132s01 <--

Furthermore, the stats log only displayed threads 1-9.

$ grep flow /var/log/suricata/stats.log | tail -20
flow.emerg_mode_entered | FlowManagerThread | 0
flow.emerg_mode_over | FlowManagerThread | 0
flow.tcp_reuse | FlowManagerThread | 0
tcp.no_flow | RxPcapenp132s01 | 0
tcp.no_flow | RxPcapenp132s02 | 0
tcp.no_flow | RxPcapenp132s03 | 0
tcp.no_flow | RxPcapenp132s04 | 0
tcp.no_flow | RxPcapenp132s05 | 0
tcp.no_flow | RxPcapenp132s06 | 0
tcp.no_flow | RxPcapenp132s07 | 0
tcp.no_flow | RxPcapenp132s08 | 0
tcp.no_flow | RxPcapenp132s09 | 0
flow_mgr.closed_pruned | FlowManagerThread | 0
flow_mgr.new_pruned | FlowManagerThread | 31431
flow_mgr.est_pruned | FlowManagerThread | 0
flow.memuse | FlowManagerThread | 464960416
flow.spare | FlowManagerThread | 1050507
flow.emerg_mode_entered | FlowManagerThread | 0
flow.emerg_mode_over | FlowManagerThread | 0
flow.tcp_reuse | FlowManagerThread | 6

This truncation in the thread names can be traced back to the following:

From tm-threads.h:
#define TM_QUEUE_NAME_MAX 16
#define TM_THREAD_NAME_MAX 16

And from util-runmodes.c, RunModeSetLiveCaptureWorkersForDevice:
for (thread = 0; thread < threads_count; thread++) {
char tname[TM_THREAD_NAME_MAX];
...
snprintf(tname, sizeof(tname), "%s%s%"PRIu16, thread_name, live_dev, thread+1);

I can certainly look into changing the name of my interface to something shorter, but I figured this was worth mentioning since RHEL7 has adopted a new interface naming convention, and this seems to cause issues with stats reporting.

Perhaps the fix is as simple as raising the #define MAX's to 32, but I wasn't sure if that would have unwanted consequences.

Actions

Also available in: Atom PDF