Packet Capture: Wireshark & tcpdump

Short answer: tcpdump records or prints packets selected by a capture filter; Wireshark decodes saved or live traffic and filters the view. Start with one question, choose a vantage point that can observe it, bound the collection, then correlate packet fields and timing with endpoint logs.

Read the troubleshooting workflow, TCP connection setup, and sequence and acknowledgment numbers.

A finish-line camera has a limited view

A race camera records who crosses one line. It cannot prove what happened around an unseen bend, and a dropped video frame can hide a runner who really passed. A packet capture has similar limits: the interface is the camera position, the capture filter selects what gets recorded, the display filter selects what you review, and timestamps put observations in order. A pcap or pcapng file is a recording, not an omniscient map of the network.

Choose the vantage point

Promiscuous mode doesn't make a switch send your laptop all other ports' unicast traffic. A Wi-Fi capture in ordinary associated mode may show Ethernet-like traffic without the 802.11 management frames needed for roaming analysis. The finish-line camera must be aimed at the relevant lane.

Capture filters and display filters are different languages

The columns express similar questions, not universally identical packet sets. dns depends on dissection, whereas port 53 selects transport ports and excludes encrypted DNS on other ports. Display filtering doesn't remove packets from the original recording. A capture filter does: you cannot recover a discarded SYN-ACK later by clearing the display filter.

A bounded Linux capture

Use only an authorized interface and target, an approved local storage location, and your organization's capture permissions. In this Linux example, eth0 and documentation address 192.0.2.20 must be replaced. GNU timeout stops after 30 seconds, or tcpdump stops after 1,000 matching packets, whichever happens first. This is not a command to run on an unrelated production interface.

tcpdump -D
sudo timeout 30s tcpdump -i eth0 -nn -s 128 -c 1000 -w handshake.pcap 'host 192.0.2.20 and tcp port 443'
tcpdump -nn -tttt -r handshake.pcap

-D lists interfaces; -nn keeps addresses and ports numeric; -s 128 retains at most 128 bytes per packet; -c limits packet count; -w writes raw packets; -r reads them later without live-capture privileges. A timeout exit status of 124 can mean the time limit was reached, not that the capture is unusable. GNU timeout isn't normally included with macOS.

A 128-byte snapshot is useful for a simple Ethernet/IPv4 TCP handshake, but can truncate tunneled headers or application data. Choose the snapshot length for the question. Even short snapshots can contain sensitive payload or names; they are not automatic anonymization. Wireshark on Windows typically uses Npcap, with interface, capture filter, and stop conditions selected in capture options. Don't run the whole GUI elevated when the supported capture-permission setup suffices.

Read one conversation from start to finish

Open the capture, identify the relevant source/destination address and ports, and isolate the conversation with a filter such as tcp.stream == 0. The stream number is assigned by Wireshark for that file, not a TCP header field. Inspect the packet list for order, the protocol tree for fields, and the bytes when a field's interpretation is in doubt.

The following synthetic client-side trace uses relative sequence numbers and contains no TCP payload. It is illustrative, not a measured benchmark or a complete tcpdump output.

A SYN consumes one sequence number, which explains Ack 1. The repeated SYN and delayed completion suggest a connection-establishment interruption. They don't prove whether the initial SYN, a reply, or capture evidence was lost. You also cannot confidently call the 20 ms interval the path RTT: the observed reply could be delayed from the original attempt. Capture at the server, align the observations, and compare logs before locating the fault. The one-second gap is illustrative, not a universal retransmission timer.

Check artifacts before blaming the wire

Two race cameras need comparable clocks before you subtract their timestamps. Likewise, synchronize capture hosts and account for clock offset and capture-hook timing. Nanosecond display precision doesn't imply nanosecond measurement accuracy. tcpdump's kernel-drop count concerns the capture mechanism, not end-to-end packet loss.

Encryption and responsible handling

TLS application data is encrypted; QUIC also encrypts much of its transport information. HTTPS traffic on UDP 443 won't appear in the TCP-only example. DNS over HTTPS won't appear in a port-53 capture. Packet timing, sizes, endpoints, and some handshake information remain useful, but visibility depends on protocol and encryption features. Use approved endpoint logs when payloads are unavailable.

Related topics

Read TCP windows and loss recovery, DNS request/reply interpretation, and HTTP over TCP and QUIC.

Sources

• tcpdump 4.99.6 manual and libpcap filter syntax. Match your installed version.
• Wireshark User's Guide: working with captured packets.
• Wireshark: offloading and capture artifacts.