Bug #7919
openSuricata generates corrupted PCAPNG files with invalid packet capture length
Description
When running Suricata in workers mode with AF-Packet and pcap-log enabled, the generated PCAPNG files are frequently corrupted at high throughput (≈10 Gbps). Tools like tcpdump, capinfos, and editcap report “invalid packet capture length … bigger than snaplen” errors.
The corruption makes the PCAP files unreadable by Wireshark and other libpcap-based tools.
Environment
Suricata version: (8.0.0, 8.0.1)
Runmode: workers
Command line:
./suricata --af-packet --runmode workers \
-c /usr/share/attackfence/detectionEngine/config/afAnalysisEngine.yaml
OS: Ubuntu 22.04
NIC driver: i40e
Traffic rate: ~10 Gbps sustained
Configuration (relevant sections)
af-packet:
- snaplen: 262144
block-size: 262144
block-timeout: 1000
buffer-size: 1048576
cluster-id: 103
cluster-type: cluster_flow
interface: eno4
ring-size: 100000
threads: 16
tpacket-v3: 'yes'
use-mmap: 'yes'
default-packet-size: 1514
max-packet-size: 1520
outputs:
- eve-log:
enabled: yes
filename: eve.json
filetype: regular
types:
- flow:
enabled: yes
metadata: yes
extended: yes
- pcap-log:
enabled: yes
mode: multi
snaplen: 262144
default-packet-size: 1514
use-stream-depth: no
honor-pass-rules: yes
dir: /var/log/attackfence/detectionEngine/pcap
filename: sensor-eno2-eno3-eno4-%t.pcapng
limit: 256mb
compression: none
Observed Behavior
Suricata runs and writes both eve.json (flows) and .pcapng files.
PCAPNG files frequently end up corrupted. Examples:
Error while reading pcap file: 'invalid packet capture length 825122333, bigger than snaplen of 262144'
capinfos: The file "sensor-eno2-eno3-eno4-1758190017.pcapng" appears to be damaged or corrupt.
(pcap: File has 3989532527-byte packet, bigger than maximum of 262144)
editcap: The file "sensor-eno4-1758196404.pcapng" appears to be damaged or corrupt.
(pcap: File has 1048255354-byte packet, bigger than maximum of 262144)
The corruption occurs after tens to hundreds of packets; capinfos sometimes stops after ~60 packets.
Expected Behavior
PCAPNG files written by pcap-log should always respect the configured snaplen (262144) and be valid/correctly parsable by Wireshark, tcpdump, editcap, etc.
Steps to Reproduce
Configure Suricata with AF-Packet + pcap-log (mode: multi) and snaplen = 262144.
Run in workers mode with 16 threads on an interface receiving ~10 Gbps traffic.
Observe that .pcapng files in the output directory become unreadable by libpcap tools due to “invalid packet capture length” errors.
Troubleshooting Attempts
Verified snaplen is consistently set to 262144 both in AF-Packet and pcap-log.
Tried editcap -s 262144 file.pcapng fixed.pcapng — still reports corruption.
Attempted reading with tcpdump and capinfos — both fail with the same invalid length errors.
Issue is reproducible consistently under 10 Gbps load.
Updated by Jason Ish about 4 hours ago
- Project changed from Suricata-Update to Suricata
- Priority changed from High to Normal
- Target version deleted (
TBD) - Effort deleted (
high) - Difficulty deleted (
high) - Label deleted (
Needs backport to 8.0)
Updated by Jason Ish about 4 hours ago
- Affected Versions 8.0.1 added
- Affected Versions deleted (
TBD)
Updated by Philippe Antoine about 2 hours ago
- Target version set to TBD
- Affected Versions 8.0.0 added