Payload reduction modes
PacketSafari anonymization is not one mode. Use different reduction strategies depending on whether you need field-aware rewrites, hard truncation, or packet-shape preservation.
Mode guide
Anoncap
Use anoncap when you need field-aware identifier anonymization.
- best when decoded fields still matter
- rewrites structured values instead of just chopping payloads
- keeps repeated identities stable inside the anonymized sibling capture
Packet slicing
Use packet slicing when you need hard payload truncation.
- best when reduction matters more than deep decoded visibility
- keeps the packet shell lighter than a full field-aware rewrite
- useful when payload suppression is the primary goal
Adaptive truncation
Use adaptive truncation when you need truncation but still want to keep inner headers for supported tunnel stacks. This is the standalone anoncap default.
- aimed at nested traffic where inner packet context still matters
- boundary-only by default: there is no fixed 256-byte target unless you pass
--snaplen <bytes> - currently covers generated regression cases for
GRE,ERSPAN,IP-in-IP,VXLAN,VXLAN-GPE,Geneve,GTP-Uwith extension headers,L2TP,Teredo,ICMPandICMPv6quotes,PPPoE,MPLS,NSH, and inner L3/L4 headers - more investigation-friendly than a blunt payload cut when the stack is supported
--public-shareselects this default profile explicitly;--nano-traceis a shorter alias--paranoidkeeps the same payload policy but adds validation, leak scanning, coverage diagnostics, uncovered-field warnings, and failure explanations
Zero-after-boundary
Use zero-after-boundary when you need to preserve packet length but blank the tail bytes after a chosen boundary.
- keeps original packet length
- destroys tail content instead of removing the bytes entirely
- useful when downstream tooling still cares about packet-size shape
PacketSafari note
PacketSafari also exposes payload trimming separately through Edit PCAP. If the real problem is application or media payload disclosure rather than structured identifiers, that can be the safer answer.
