The tool said it wrote 48 packets. Only 44 were there

Description and use

A bug in PcapSplitter caused packet loss due to filename collisions when reusing 5‑tuples. The fix added a suffix on collision and tests, eliminating truncation and race conditions.

Problem

A custom PCAP splitter tool reported 48 packets but only 44 were actually written to disk, indicating file truncation or corruption during session reuse.

Outcome

The bug was caused by filename collision on TCP session reuse, leading to file truncation or corruption. A targeted patch added a collision suffix and tests, resolving the issue and preventing future data loss.

Workflow

• 1. Observe mismatch between reported and actual packet count.
• 2. Reproduce with minimal 13‑connection test case.
• 3. Investigate theories: file descriptor exhaustion and hardcoded LRU limit – both ruled out.
• 4. Inspect FiveTupleSplitter::getFileNumber and getFileName logic – discover fileNumber is ignored for TCP/UDP paths.
• 5. Trace main.cpp writer cache – new fileNum opens file without append, truncating or racing with existing writer.
• 6. Identify root cause: identical filenames for reused 5‑tuples.
• 7. File issue on GitHub (#2248).
• 8. Propose fix: suffix filename only on collision, preserve original for first session.
• 9. Implement code change and unit tests.
• 10. Submit PR (#2249) and merge after maintainer approval.

Evidence

PcapSplitter reported 12 files and 48 packets, but on disk, there were 11 files and 44 packets.

Source

Because fileNumber is dropped, the new session produces the identical filename string as the older session.

Source

Merged #2249

Source