Suricata

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.