Bug #3040
open
pcap: with -r <single file> pcap_open_offline failure does not lead to non-zero exit code
Added by Victor Julien almost 5 years ago.
Updated almost 3 years ago.
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
- Assignee set to OISF Dev
- Target version set to TBD
How did you trigger this, so I can reproduce it?
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.
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.
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
Also available in: Atom
PDF