Project

General

Profile

Actions

Bug #3040

open

pcap: with -r <single file> pcap_open_offline failure does not lead to non-zero exit code

Added by Victor Julien over 3 years ago. Updated about 1 year ago.

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

Description

[19811] 11/6/2019 -- 18:21:03 - (suricata.c:1067) <Notice> (LogVersion) -- This is Suricata version 5.0.0-dev (rev b5f3e0320) running in USER mode
[19812] 11/6/2019 -- 18:21:03 - (source-pcap-file-helper.c:174) <Error> (InitPcapFile) -- [ERRCODE: SC_ERR_FOPEN(44)] - invalid interface capture length 524288, bigger than maximum of 262144
[19812] 11/6/2019 -- 18:21:03 - (source-pcap-file.c:274) <Warning> (ReceivePcapFileThreadInit) -- [ERRCODE: SC_ERR_PCAP_DISPATCH(20)] - Failed to init pcap file <pcap file>, skipping
[19811] 11/6/2019 -- 18:21:03 - (tm-threads.c:2157) <Notice> (TmThreadWaitOnThreadInit) -- all 5 packet processing threads, 4 management threads initialized, engine started.
[19812] 11/6/2019 -- 18:21:03 - (source-pcap-file.c:161) <Error> (ReceivePcapFileLoop) -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - pcap file reader thread failed to initialize
[19811] 11/6/2019 -- 18:21:03 - (suricata.c:2843) <Notice> (SuricataMainLoop) -- Signal Received.  Stopping engine.
# echo $?
0

Expected outcome is that this would return an error.

Files

cap_00001_20210622092340.pcap (1.04 MB) cap_00001_20210622092340.pcap Phil Rzewski, 07/06/2021 06:26 PM
Actions #1

Updated by Andreas Herz over 3 years ago

  • Assignee set to OISF Dev
  • Target version set to TBD

How did you trigger this, so I can reproduce it?

Actions #2

Updated by Victor Julien over 3 years ago

This was with a pcap that had a capture size of 512k, which my libpcap rejects. Can't share the pcap itself. Maybe it's possible to craft one.

Actions #3

Updated by Danny Browning about 3 years ago

This is an outcome of not having the process not return the thread error information when the initialize fails.

The thread initialize has to return ok, otherwise the thread error information is output instead.

Actions #4

Updated by Phil Rzewski about 1 year ago

I bumped into a similar issue on Suricata v6.0.3 on macOS, and I have a pcap I can share that reproduces it, so I figured I'd mention it here rather than open yet another issue. If it's different enough that it justifies its own issue, let me know and I'm happy to open it.

The test pcap cap_00001_20210622092340.pcap is attached. It's got encapsulation that Suricata does not appear to support, which is fine of course. But the exit code of 0 threw us for a loop since we're integrating this with other tooling that would have expected a non-zero exit code to reflect the failure communicated in the error messages.

$ suricata -V
This is Suricata version 6.0.3 RELEASE

$ suricata -r cap_00001_20210622092340.pcap 
6/7/2021 -- 11:27:58 - <Notice> - This is Suricata version 6.0.3 RELEASE running in USER mode
6/7/2021 -- 11:28:09 - <Error> - [ERRCODE: SC_ERR_UNIMPLEMENTED(88)] - datalink type 127 not (yet) supported in module PcapFile.
6/7/2021 -- 11:28:09 - <Warning> - [ERRCODE: SC_ERR_PCAP_DISPATCH(20)] - Failed to init pcap file cap_00001_20210622092340.pcap, skipping
6/7/2021 -- 11:28:09 - <Notice> - all 13 packet processing threads, 4 management threads initialized, engine started.
6/7/2021 -- 11:28:09 - <Error> - [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - pcap file reader thread failed to initialize
6/7/2021 -- 11:28:09 - <Notice> - Signal Received.  Stopping engine.

$ echo $?
0
Actions

Also available in: Atom PDF