THE CATEGORY ERROR
The capture is a measurement, not the thing being measured.
A packet capture looks authoritative because it is granular. It gives timestamps, addresses, ports, flags, sequence numbers, lengths, protocol fields, payload bytes when visible, and enough hexadecimal to make everyone in the room briefly respectful. That density is useful. It is also dangerous when it creates the impression that the file contains everything that happened.
It does not.
A capture contains packets that reached a specific capture path, at a specific point in the network or host stack, under a specific set of interface, driver, buffering, filtering, timestamping, and storage conditions. Anything outside that observation surface can be absent, transformed, aggregated, reordered, dropped, encrypted, or represented differently than it appeared on the wire.
The first question in serious packet analysis therefore is not what does the trace say? It is what exactly was capable of entering this trace?
CAPTURE POINT
Where you stand determines what exists.
An endpoint capture, a switch mirror port, a hardware tap, a router interface, a virtual switch, a container namespace, a VPN interface, and a cloud traffic mirror can all observe different versions of the same conversation.
Capture on the transmitting host and you may see a packet before the network interface card has finished it. Capture on the receiving host and you may see the packet only after link-layer validation and some driver processing. Capture on a mirrored switch port and oversubscription, configuration, VLAN treatment, or hardware limitations may affect what is copied to you. Capture inside a virtual machine and the hypervisor or virtual switch may be doing things the guest cannot observe.
Even the phrase “the same packet” needs care. A large host-side buffer may later be segmented by offload machinery into multiple frames on the wire. Conversely, received traffic may be coalesced before some host-side observation points see it. The file can be internally accurate while still representing a different stage of packet life than the analyst assumes.
Document the observation point like an instrument location: host, interface, direction, topology role, virtualization layer, mirror/tap method, link speed, and any known translation or tunnel boundary.
OFFLOADS
The NIC is allowed to finish your packet after you captured it.
Modern network stacks deliberately push work into hardware. Checksum offload, segmentation offload, receive aggregation, and related optimizations reduce CPU load and increase throughput. They also make host-local captures look strange if the analyst expects every captured frame to be a literal wire image.
One common example is checksum offload. A transmitting host may hand a packet to the capture path before the interface hardware has calculated the final checksum. The trace may therefore show an apparently invalid TCP or UDP checksum even though the frame sent on the wire is valid. That is not hypothetical weirdness; Wireshark documents it explicitly.
Segmentation offload can create similarly confusing packet sizes. The operating system may hand a large logical buffer toward the NIC, where hardware later segments it into MTU-sized frames. A host capture taken before that transformation may therefore contain packet representations that would never appear as single Ethernet frames on the physical link.
The practical rule is simple: when a trace contains impossible-looking checksum or segmentation behavior, ask whether the capture point is seeing a pre-offload or post-offload representation before declaring the network haunted.
PACKET LOSS
A missing packet and an unobserved packet are not the same claim.
Capture systems have buffers. Buffers fill. CPUs fall behind. Storage stalls. Drivers drop. Interfaces drop. Filters behave differently across platforms. A high-rate capture can lose packets while the production traffic itself continues normally.
Libpcap exposes capture statistics such as packets received, packets dropped because the operating-system capture buffer had no room, and packets dropped by an interface or driver where the platform reports them. The ugly detail is that these counters do not behave identically on every platform. A zero is not automatically proof of zero loss.
That means every serious capture should preserve available capture statistics alongside the packet file. “No SYN observed” is much weaker if the capture process reported drops. “The server never replied” is different from “this observation point recorded no reply.” Wording matters because the second statement survives evidence review.
For sustained collection, capture-only tools, appropriate buffer sizing, ring buffers, and storage planning can matter more than a beautiful live GUI. Analysis is allowed to happen later. Lost packets are less accommodating.
TIMESTAMPS
A timestamp has a source, precision, and failure mode.
Packet timing often becomes evidence for latency, retransmission, ordering, jitter, request-response relationships, and distributed-system failures. Those conclusions are only as strong as the clocks behind them.
A timestamp may come from software in the host networking path or from capable hardware closer to the interface. Linux packet-socket documentation explicitly distinguishes software and raw hardware timestamp sources. Neither should be treated as abstract universal time.
Across multiple capture systems, clock offset and drift can dominate the event you are trying to measure. Two capture boxes can each have microsecond-resolution timestamps and still disagree by milliseconds or seconds because resolution is not synchronization. NTP state, PTP state, hardware timestamp configuration, clock source, timezone handling, and known adjustment events belong in the provenance record when timing matters.
Never infer causality from timestamp order across machines until you understand whether the clocks justify it.
ENCRYPTION
A complete packet record can still hide the application event.
TLS, QUIC, VPN tunnels, encrypted DNS, and application-layer encryption can leave transport metadata visible while hiding content. A trace may accurately show endpoints, timing, lengths, direction, handshake behavior, retransmissions, connection setup, and some protocol metadata while remaining unable to tell you what semantic action occurred inside the encrypted stream.
This is where analysts sometimes commit a different category error: translating network metadata into application certainty. A burst of encrypted packets may correlate with a login, message, synchronization job, software update, media transfer, telemetry batch, or something else entirely.
Network evidence becomes much stronger when paired with server logs, client logs, application audit events, traces, metrics, configuration state, and endpoint timestamps. Observability is a multi-instrument problem. Packet capture is one instrument.
FILTERS + SNAPLEN
You can discard evidence deliberately without noticing later.
Capture filters are useful precisely because they exclude traffic. Snapshot length limits are useful precisely because they truncate packets. Ring buffers are useful precisely because they overwrite older files. Those are engineering tradeoffs, not moral failures, but they must be recorded.
If a capture was filtered to a host, port, protocol, VLAN, or address range, later analysts need the exact filter. If packets were truncated after a fixed number of bytes, they need the snapshot length. If a ring buffer rotated through a finite set of files, they need the retention geometry and rotation rule.
A trace cannot answer a question about evidence the collection policy intentionally threw away. Future-you is an analyst too, and future-you will absolutely forget what present-you thought was obvious.
REASSEMBLY + INTERPRETATION
The analyzer is also a model.
Protocol analyzers do more than print bytes. They infer conversations, decode fields, reassemble streams, match requests to responses, apply heuristics, identify protocols on nonstandard ports, and maintain internal state. Those features are why they are useful. They are also another interpretation layer.
Malformed traffic, missing segments, checksum handling, asymmetric capture, retransmissions, overlapping fragments, unusual encapsulation, version differences, and dissector bugs can change what the analyzer presents. If a conclusion matters, inspect the underlying frame fields and raw bytes instead of relying entirely on a generated summary column.
“Wireshark says” is not a mechanism. The useful statement is: these captured bytes, interpreted under this dissector and reassembly state, support this conclusion.
TOPOLOGY
Absence depends on the route the traffic actually took.
A mirrored port cannot show traffic that bypassed the mirrored path. An endpoint cannot show a conversation that terminated elsewhere. A single direction of a load-balanced service may traverse a different device from the return direction. East-west traffic inside a virtual environment may never touch the physical interface where somebody thoughtfully connected the expensive analyzer.
Before diagnosing from absence, sketch the path. Include NAT, load balancers, tunnels, service meshes, firewalls, virtual switches, containers, VPNs, redundant links, and any asymmetric routing possibilities. Then mark exactly where the capture was taken.
If the packet could have taken another path, “not in this trace” is evidence about the observation point before it is evidence about the network.
PROVENANCE
A packet file without acquisition metadata is weaker than it needs to be.
Cyberdelia’s preferred packet-capture record is not just incident.pcapng. It is the packet file plus enough context to reconstruct the measurement.
Minimum useful acquisition record: capture file name; SHA-256; start/end time; capture host; OS/kernel version; capture tool and version; interface name/type; interface addresses; capture point/topology role; link speed where known; promiscuous/monitor mode state; exact capture filter; snapshot length; capture buffer size where known; available drop statistics; timestamp source where known; interface offload state when relevant; time-synchronization state; rotation/ring-buffer policy; operator; case/project ID; notes describing known gaps.
That sounds bureaucratic until two weeks later when somebody asks whether the “bad checksums” were captured on the transmitting host with checksum offload enabled. Then it sounds like memory.
LAB METHOD
When the conclusion matters, triangulate.
A disciplined diagnostic pass can be simple:
1. Define the question. “Why is the application slow?” is too broad. “Is 400 ms being spent before the server sends its first response byte?” is testable.
2. Mark the expected path. Draw the route and capture boundaries.
3. Capture at the most informative point. Sometimes that is an endpoint. Sometimes it is both endpoints. Sometimes the only honest answer requires two observation points.
4. Record capture state. Filters, buffers, drops, clock state, offloads, and tool versions.
5. Preserve the original. Hash the acquired trace and perform transformations or redaction on derivatives.
6. Compare another instrument. Logs, application traces, counters, switch telemetry, firewall events, service metrics, or a second packet observation point.
7. State the conclusion at the strength the evidence supports. Prefer “not observed at point A” over “did not happen” unless you have actually closed the alternative paths.
FAILURE MATRIX
Common packet-analysis mistakes and what they actually mean.
“Bad checksum means corrupt packet.”
Maybe. On a transmitting host it may be checksum offload. Determine where checksum completion occurs.
“The packet is huge, therefore MTU is broken.”
Maybe. Host-side segmentation offload can expose large logical buffers before wire segmentation.
“The response never happened.”
The response was not observed in this capture. Check capture loss, topology, asymmetry, filters, and a second source.
“These events happened in this order.”
On one well-behaved clock, perhaps. Across hosts, prove synchronization first.
“The application sent command X.”
If the payload is encrypted, packet timing and size alone rarely justify that semantic certainty.
“Zero drops means complete capture.”
Not universally. Capture statistics and reporting differ across platforms and paths.
“The analyzer decoded it as protocol Y, so it is protocol Y.”
Inspect the basis of the heuristic or dissector when the distinction matters.
FIELD RULES
What a packet capture can prove depends on how it was made.
Packet evidence is enormously powerful because networks expose behavior at boundaries. It can reveal timing, retransmission, failed negotiation, unexpected peers, protocol violations, routing symptoms, service dependencies, and the difference between what software claimed to send and what another observer actually saw.
Its strength increases when analysts stop demanding omniscience from it.
A packet capture is not the network. It is testimony from one instrument standing somewhere in the network.
Know where the witness was standing.
SOURCE TRAIL
Primary technical references.
Wireshark User’s Guide — Checksums and checksum offloading
Wireshark Wiki — Capture offloading behavior
Wireshark Developer’s Guide — Capturing packets
libpcap pcap_stats(3) — capture and drop counters
Linux kernel documentation — PACKET_MMAP and packet timestamp sources