Project

General

Profile

Actions

Bug #1405

closed

Segfault on Fedora 21 with af-packet mode

Added by Casey Dunham about 9 years ago. Updated about 8 years ago.

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

Description

We are testing Suricata (2.0.6) in af-packet mode on a Fedora 21 system and had it crash this morning. The suricata service stopped running and did not come back.

Details:

$ uname -a

Linux ips.bigelow.org 3.17.4-301.fc21.x86_64 #1 SMP Thu Nov 27 19:09:10 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ rpm -qa | grep suricata

suricata-2.0.6-1.fc21.x86_64

Here is the segfault from /var/log/messages

$ sudo tail /var/log/messages

Mar  5 09:38:55 ips kernel: [151290.125455] Detect1[1596]: segfault at 4 ip 00007fde45cb331b sp 00007fde3d155470 error 4 in suricata[7fde45bd1000+201000]
Mar  5 09:38:55 ips [1579]: [Drop] [1:2003313:3] ET P2P Edonkey Connect Reply and Server List [Classification: Potential Corporate Privacy Violation] [Priority: 1] {UDP} 73.0.97.102:48602 -> 10.2.3.112:29792
Mar  5 09:38:55 ips kernel: Detect1[1596]: segfault at 4 ip 00007fde45cb331b sp 00007fde3d155470 error 4 in suricata[7fde45bd1000+201000]
Mar  5 09:39:38 ips kernel: [151333.103935] device enp4s0f0 left promiscuous mode
Mar  5 09:39:38 ips kernel: device enp4s0f0 left promiscuous mode
Mar  5 09:39:38 ips kernel: [151333.136983] device enp4s0f1 left promiscuous mode
Mar  5 09:39:38 ips kernel: device enp4s0f1 left promiscuous mode
Mar  5 09:39:38 ips systemd: suricata.service: main process exited, code=killed, status=11/SEGV
Mar  5 09:39:38 ips systemd: Unit suricata.service entered failed state.
Mar  5 09:39:38 ips systemd: suricata.service failed.

There is nothing in /var/log/suricata/suricata.log. The last detect in the /var/log/suricata/fast.log is the above drop for the Edonkey traffic.


Files

suricata.yaml (38.4 KB) suricata.yaml Casey Dunham, 03/05/2015 10:37 AM
Actions #1

Updated by Victor Julien almost 9 years ago

  • Description updated (diff)

Can you try to get a back trace? See Reporting_Bugs

Actions #2

Updated by Andreas Moe almost 9 years ago

Could the be related to #1406? I see that you are using NICs that have long names enp4s0f1 (8 chars). this pluss the current thread naming style would give to long names for pthread to handle correctly).

Actions #3

Updated by Victor Julien about 8 years ago

  • Status changed from New to Closed

Timeout.

Actions

Also available in: Atom PDF