Project

General

Profile

Actions

Bug #8464

open
PS

Libpcap fails to get first packet timestamp when reading a pcap from a named pipe or stdin

Bug #8464: Libpcap fails to get first packet timestamp when reading a pcap from a named pipe or stdin

Added by Pim Sanders 18 days ago. Updated 18 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
Affected Versions:
Effort:
Difficulty:
Label:
C, Needs backport to 8.0

Description

When Suricata 8 (or HEAD at main) is started in pcap file/offline mode with a PCAP from a named pipe or stdin, reading the PCAP fails with the following error:

Error: pcap: failed to get first packet timestamp. pcap_next_ex(): -1 [PeekFirstPacketTimestamp:source-pcap-file-helper.c:186]
Warning: pcap: Failed to init pcap file /dev/stdin, skipping [ReceivePcapFileThreadInit:source-pcap-file.c:301]

This same issue was raised by wesley.vanderree on the forum [1]:

I’m experiencing some issues when running reading pcaps from stdin. I’m quite sure this was possible in Suricata 7.0.8 and stopped working in Suricata 8.

I have seen at least the following errors in the logs: (2 different pcaps..)

[1339269 - W#01] 2025-09-15 11:53:39 Error: pcap: failed to get first packet timestamp. pcap_next_ex(): -1
[1339611 - W#01] 2025-09-15 11:58:12 Error: pcap: error code -1 invalid packet capture length 745042785, bigger than snaplen of 65535 for /dev/stdin

I have a gut feeling it has something to do with the implementation of the “HAVE_SETVBUF” patches that are implemented in suricata 8. but I cannot put my finger on the exact issue.

On further investigation it seems the issue is indeed caused by the HAVE_SETVBUF patches introduced in commit 7b730c2 [2,3]. The minimum PCAP buffer size is set to 4 KiB, which means that setvbuf will always be used. setvbuf tries to seek the position of the first packet but fails because the named pipe is not seekable. We have encountered this issue on systems running Debian and Fedora, but not on Alpine. Presumably because of differences in the setvbuf implementation between glibc and musl.

Changing the PCAP_FILE_BUFFER_SIZE_MIN to 0 and running Suricata with --pcap-file-buffer-size=0 allows reading from named pipes and stdin again.
Changes:

diff --git a/src/source-pcap-file.c b/src/source-pcap-file.c
index 808fe27b6..5b7b00b05 100644
--- a/src/source-pcap-file.c
+++ b/src/source-pcap-file.c
@@ -140,7 +140,7 @@ void TmModuleDecodePcapFileRegister (void)

 #if defined(HAVE_SETVBUF) && defined(OS_LINUX)
 #define PCAP_FILE_BUFFER_SIZE_DEFAULT 131072U   // 128 KiB
-#define PCAP_FILE_BUFFER_SIZE_MIN     4096U     // 4 KiB
+#define PCAP_FILE_BUFFER_SIZE_MIN     0         // 0 B
 #define PCAP_FILE_BUFFER_SIZE_MAX     67108864U // 64MiB
 #endif

I have thus far not found any problems with running PCAP_FILE_BUFFER_SIZE_MIN set to 0, but I'm also not entirely sure if this is the preferred approach.

References:
[1]: https://forum.suricata.io/t/suricata-8-0-0-seems-to-not-read-pcap-files-correctly-from-stdin/6016
[2]: https://github.com/OISF/suricata/blob/main/src/source-pcap-file.c#L143
[3]: https://github.com/OISF/suricata/commit/7b730c2e682eba8c769d01e56f2568dc0fbfcc67

PS Updated by Pim Sanders 18 days ago Actions #1

When Suricata 8 (or HEAD at main) is started in pcap file/offline mode with a PCAP from a named pipe or stdin, reading the PCAP fails with the following error:

Error: pcap: failed to get first packet timestamp. pcap_next_ex(): -1 [PeekFirstPacketTimestamp:source-pcap-file-helper.c:186]
Warning: pcap: Failed to init pcap file /dev/stdin, skipping [ReceivePcapFileThreadInit:source-pcap-file.c:301]

This same issue was raised by wesley.vanderree on the forum [1]:

I’m experiencing some issues when running reading pcaps from stdin. I’m quite sure this was possible in Suricata 7.0.8 and stopped working in Suricata 8.

I have seen at least the following errors in the logs: (2 different pcaps..)

[1339269 - W#01] 2025-09-15 11:53:39 Error: pcap: failed to get first packet timestamp. pcap_next_ex(): -1
[1339611 - W#01] 2025-09-15 11:58:12 Error: pcap: error code -1 invalid packet capture length 745042785, bigger than snaplen of 65535 for /dev/stdin

I have a gut feeling it has something to do with the implementation of the “HAVE_SETVBUF” patches that are implemented in suricata 8. but I cannot put my finger on the exact issue.

On further investigation it seems the issue is indeed caused by the HAVE_SETVBUF patches introduced in commit 7b730c2 [2,3]. The minimum PCAP buffer size is set to 4 KiB, which means that setvbuf will always be used. setvbuf internally tries to reset the file position but fails because the file (/dev/stdin, or named pipes) is not seekable it creates an inconsistent state. We have encountered this issue on systems running Debian and Fedora, but not on Alpine. Presumably because of differences in the setvbuf implementation between glibc and musl.

Changing the PCAP_FILE_BUFFER_SIZE_MIN to 0 and running Suricata with --pcap-file-buffer-size=0 allows reading from named pipes and stdin again.
Changes:

diff --git a/src/source-pcap-file.c b/src/source-pcap-file.c
index 808fe27b6..5b7b00b05 100644
--- a/src/source-pcap-file.c
+++ b/src/source-pcap-file.c
@@ -140,7 +140,7 @@ void TmModuleDecodePcapFileRegister (void)

 #if defined(HAVE_SETVBUF) && defined(OS_LINUX)
 #define PCAP_FILE_BUFFER_SIZE_DEFAULT 131072U   // 128 KiB
-#define PCAP_FILE_BUFFER_SIZE_MIN     4096U     // 4 KiB
+#define PCAP_FILE_BUFFER_SIZE_MIN     0         // 0 B
 #define PCAP_FILE_BUFFER_SIZE_MAX     67108864U // 64MiB
 #endif

I have thus far not found any problems with running PCAP_FILE_BUFFER_SIZE_MIN set to 0, but I'm also not entirely sure if this is the preferred approach.

References:
[1]: https://forum.suricata.io/t/suricata-8-0-0-seems-to-not-read-pcap-files-correctly-from-stdin/6016
[2]: https://github.com/OISF/suricata/blob/main/src/source-pcap-file.c#L143
[3]: https://github.com/OISF/suricata/commit/7b730c2e682eba8c769d01e56f2568dc0fbfcc67

Actions

Also available in: PDF Atom