How to prepare a PCAP for vendor support without leaking the whole capture

Packet captures are useful because they are specific. They are risky for the same reason. A raw PCAP can contain:

• internal IP addresses
• hostnames
• credentials or tokens in cleartext protocols
• cookies
• DNS queries
• customer traffic unrelated to the bug
• proprietary endpoints
• timing information
• enough context to reveal network architecture

Before sending a capture to a vendor, support team, customer, or public issue, treat it like evidence that needs minimization. The goal is not to make the file pretty. The goal is to preserve the packets needed to reproduce or explain the issue while removing everything that does not belong in the handoff.

Start with the question

Do not edit a PCAP until you know what the receiver needs to answer. Examples:

• Why does TLS negotiation fail after ServerHello?
• Why does this device retransmit every request?
• Why does the API return 400 only for this payload?
• Why does the camera stream freeze after PLAY?
• Why does DNS resolve differently on this subnet?

That question tells you which packets matter.

Keep a read-only original

Always preserve the original capture. Recommended structure:

case-1234/
  original/
    customer-capture-raw.pcapng
  working/
    filtered-draft.pcapng
  handoff/
    vendor-handoff-v1.pcapng
    notes.md

Never overwrite the original file. If a later question appears, you may need to rebuild the handoff from the untouched source.

Reduce the time window

The easiest safe reduction is time. If the failure happens between 10:42:13 and 10:42:18, the vendor probably does not need a 45-minute capture. Keep:

• a small lead-in before the failure
• the failure itself
• enough aftermath to show retries, resets, or recovery

Remove unrelated browsing, background sync, update checks, and other noise.

Filter by conversation, not just protocol

Protocol filters are often too broad. Instead of "all HTTP" or "all DNS", narrow to:

• client IP
• server IP
• port
• stream/conversation
• device MAC
• transaction ID
• request path if visible

A narrow conversation makes review faster and reduces accidental disclosure.

Redact identifiers deliberately

Common fields to inspect before sharing:

• IP addresses
• MAC addresses
• Hostnames
• DNS queries
• HTTP headers
• URLs and query strings
• Cookies
• Authorization headers
• Email addresses
• Usernames
• Device serial numbers
• Payload strings

Redaction should be intentional. Replacing every IP with nonsense can destroy routing evidence. Leaving every internal hostname can leak environment details. A good rule:

• preserve structure needed for diagnosis
• remove identities not needed for diagnosis
• document what changed

Repair checksums when rewriting

If you modify packet bytes, addresses, or headers, checksums may no longer match. Some tools ignore bad checksums. Some analysis tools and test harnesses do not. After editing, check:

• IP header checksum
• TCP checksum
• UDP checksum
• transport length fields
• capture file format validity

If the file is meant for replay, testing, or regression fixtures, checksum correctness matters more.

Add a short handoff note

Do not send a PCAP alone. Include a note like:

Case: login request fails after TLS renegotiation
Original capture retained internally: yes
Shared file time window: 10:42:10-10:42:22 UTC
Included hosts: client 10.0.0.15, api.example.internal
Redactions: client IP anonymized, hostname shortened, cookies removed
Checksums repaired: yes
Expected symptom: server closes connection after packet 184
Question for vendor: is this close_notify behavior expected?

That note prevents the receiver from reverse-engineering your intent.

Validate the final file

Before sending:

• [ ] Opens in Wireshark/tshark
• [ ] Contains the failure
• [ ] Does not contain unrelated traffic
• [ ] Redactions are documented
• [ ] Checksums are valid if needed
• [ ] File size is reasonable
• [ ] Receiver knows what question to answer

Where PCAP Surgery fits

You can do parts of this with Wireshark, editcap, text notes, and scripts. The problem is that safe support handoff is a workflow, not one command. I build PCAP Surgery for that workflow: review, trim, redact, repair checksums, and export focused PCAP/PCAPNG files from a local desktop workbench. It is not a live packet sniffer, IDS, VPN, or traffic generator. It is for preparing packet evidence that can be safely handed to another person.

Disclosure: I build PCAP Surgery.

Minimal handoff checklist

• [ ] Define the support question
• [ ] Preserve the original capture
• [ ] Trim the time window
• [ ] Keep only relevant conversations
• [ ] Redact sensitive identifiers
• [ ] Repair checksums if rewriting
• [ ] Export a focused PCAP/PCAPNG
• [ ] Send a short note with the file