pcap-file: skip setvbuf on non-seekable streams (v4) - #15631
Closed
ssam18 wants to merge 1 commit into
Closed
Conversation
Reading a pcap from /dev/stdin or a named pipe currently fails with "failed to get first packet timestamp. pcap_next_ex(): -1" because InitPcapFile calls setvbuf on the FILE* underlying the pcap handle after libpcap has already consumed the pcap header. On a non-seekable fd glibc cannot recover from that and the next read returns -1. Detect non-regular files via fstat and skip setvbuf in that case so the read keeps working on pipes, fifos and stdin. Accept pcap-file.buffer-size values of 0, which disables setvbuf buffering as an explicit opt-out, or PCAP_FILE_BUFFER_SIZE_MIN (4 KiB) to PCAP_FILE_BUFFER_SIZE_MAX (64 MiB). Treat any non-zero setvbuf return value as an error, not just negative values. When pcap-file.buffer-size fails to parse, retain the default buffer size instead of falling through and setting it to 0. The branches are now mutually exclusive so only one of the parse-error, accepted, or out-of-range messages is logged. Update the user guide: --pcap-file-buffer-size now documents valid values of 0 (disables setvbuf buffering) or 4 KiB to 64 MiB, and pcap-file.rst notes that 0 is the opt-out for non-seekable sources such as stdin and named pipes. Bug: OISF#8464.
5 tasks
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #15631 +/- ##
=======================================
Coverage 82.87% 82.88%
=======================================
Files 1006 1006
Lines 273527 273538 +11
=======================================
+ Hits 226698 226716 +18
+ Misses 46829 46822 -7
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
victorjulien
approved these changes
Jun 12, 2026
Merged
Member
|
Merged in #15636, thanks! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Make sure these boxes are checked accordingly before submitting your Pull Request -- thank you.
Contribution style:
https://docs.suricata.io/en/latest/devguide/contributing/contribution-process.html
Our Contribution agreements:
https://suricata.io/about/contribution-agreement/ (note: this is only required once)
Changes (if applicable):
(including schema descriptions)
https://redmine.openinfosecfoundation.org/projects/suricata/issues
Link to ticket: https://redmine.openinfosecfoundation.org/issues/8464
Replaces #15629.
Changes since #15629
source-pcap-file.cwas still 2007-2016;source-pcap-file-helper.calready included 2026). (Addresses @jlucovsky's review.)Description
Reading a pcap from /dev/stdin or a named pipe regressed in 8.0.0 with the setvbuf change in 7b730c2 and currently fails with
failed to get first packet timestamp. pcap_next_ex(): -1. The reason is that InitPcapFile calls setvbuf on the FILE* underlying the pcap handle after libpcap has already consumed the pcap header, and on a non seekable fd glibc cannot recover from that and the very next read returns -1. This change detects non regular files via fstat on the underlying fd and skips setvbuf for that handle, so reading from stdin, named pipes, and other non seekable sources keeps working.pcap-file.buffer-size = 0remains available as an explicit opt out, matching the workaround proposed on the ticket.Describe changes:
SV_BRANCH=OISF/suricata-verify#3108