Wireshark Cheatsheet

Protocol Analysis

Use this Wireshark reference while you build software engineering projects, review code, or refresh the syntax you reach for most.

Reading the Detail Pane

The middle pane is the dissection tree, one node per protocol layer, outermost first. Select a node and the byte pane highlights exactly the bytes it covers, which is the fastest way to learn a header layout.

Key	Action
`→` / `←`	Expand or collapse the selected subtree
`Shift+→` / `Shift+←`	Expand or collapse all subtrees under it
`Ctrl+→` / `Ctrl+←`	Expand all, collapse all
`Backspace`	Jump to the parent node
Right-click → Copy → As Filter	Put the exact filter for this field on the clipboard
Right-click → Copy → Field Name / Value	For scripting
Right-click → Go to Linked Packet	Jump to the request that this response answers

Bracketed nodes in [square brackets] are generated by Wireshark, not on the wire. [Stream index: 4], [Time since request: 0.204s], [SEQ/ACK analysis], [Expert Info], and [Calculated window size] are all computed. They are filterable, but do not go looking for them in the hex.

The byte pane has tabs at the bottom. Frame is the packet as captured, and extra tabs like Reassembled TCP or Decrypted TLS appear when a dissector produced a larger buffer than one frame carries.

Decode As

When a service runs on a nonstandard port, Wireshark guesses wrong. Right-click a packet → Decode As…, or Analyze → Decode As…, add a row, and pick the dissector. Entries persist in the profile's decode_as_entries.

# Same override on the command line, repeatable
tshark -r cap.pcapng -d tcp.port==8888,http
tshark -r cap.pcapng -d tcp.port==8443,tls -Y http
tshark -r cap.pcapng -d udp.port==5353,mdns
tshark -r cap.pcapng -d "tcp.port==9092,kafka"

# What can be decoded as what
tshark -d . 2>&1 | head -40

Related controls:

Control	Where	Effect
`Analyze → Enabled Protocols`	GUI	Turn a dissector off entirely
`--disable-protocol <name>`	tshark	Same, for one run
`--only-protocols tcp,ip,eth`	tshark	Disable everything else, much faster
`--enable-heuristic` / `--disable-heuristic`	tshark	Heuristic dissectors, the ones that guess
`Analyze → Decode As`	GUI	Port-to-dissector override

Turning a dissector off is a real diagnostic. If a packet is being mangled by an overeager heuristic dissector, disabling it shows you the raw TCP payload.

Expert Information

Analyze → Expert Information is every problem the dissectors noticed, grouped by severity and summary, with a count and a click-through to the packets.

Severity	Color	Means
Error	Red	Malformed packet, dissection failed
Warning	Yellow	Something is wrong on the wire, e.g. a previous segment not captured
Note	Cyan	Unusual but legal, e.g. a retransmission or a duplicate ACK
Chat	Blue	Normal protocol events, connection setup and teardown
Comment	Green	A packet comment stored in the file

tshark -r cap.pcapng -q -z expert
tshark -r cap.pcapng -q -z expert,note      # note and above only
tshark -r cap.pcapng -Y "_ws.expert.severity >= 0x00600000"   # warn + error

Open a capture you have never seen with Expert Information first. It tells you in one screen whether the file has packet loss, checksum failures, or malformed frames, before you write a single filter.

TCP Analysis Flags

The TCP dissector maintains per-stream state and annotates packets. These are the fields that make performance work possible. They are heuristics computed from what was captured, so a lossy capture invents problems that the network did not have.

Field	Wireshark decided
`tcp.analysis.retransmission`	These bytes were seen before
`tcp.analysis.fast_retransmission`	A retransmission right after duplicate ACKs
`tcp.analysis.spurious_retransmission`	Retransmitted data that was already acknowledged
`tcp.analysis.out_of_order`	Lower sequence number arriving late, but not a retransmission
`tcp.analysis.lost_segment`	A sequence gap, "previous segment not captured"
`tcp.analysis.duplicate_ack`	Same ACK number again, with `duplicate_ack_num` counting them
`tcp.analysis.zero_window`	Receiver advertised a window of 0, it has stopped reading
`tcp.analysis.window_full`	Sender has filled the advertised window and must wait
`tcp.analysis.window_update`	Receiver reopened the window, not a problem
`tcp.analysis.keep_alive`	Zero or one byte probe on an idle connection
`tcp.analysis.reused_ports`	A new SYN on a 4-tuple that was already in use
`tcp.analysis.ack_rtt`	Seconds until this segment was acknowledged
`tcp.analysis.bytes_in_flight`	Unacknowledged bytes at this moment
`tcp.analysis.flags`	Any of the above except the benign ones

tcp.analysis.flags && !tcp.analysis.window_update
tcp.analysis.lost_segment or tcp.analysis.out_of_order
tcp.analysis.zero_window
tcp.analysis.ack_rtt > 0.2
tcp.analysis.bytes_in_flight > 65535

Two preferences change these numbers a lot. Relative sequence numbers makes sequence values readable but hides the real ISN, and Calculate conversation timestamps must be enabled before tcp.time_delta exists at all.

Protocol Notes That Bite

TCP. tcp.len is payload length, frame.len is the whole frame. A pure ACK has tcp.len == 0. tcp.completeness tells you whether the capture holds the whole connection, which decides whether the analysis flags mean anything.

HTTP. http.request and http.response are the two halves. http.time on a response is the latency, and http.request_in links back to the request frame. HTTP/2 is a different dissector, http2, with header compression, so a header you search for as a literal string will not be in the bytes.

TLS. Only the handshake is readable without keys. tls.handshake.type == 1 is the ClientHello, and its tls.handshake.extensions_server_name gives the hostname in cleartext. Certificates are in the ServerHello flight for TLS 1.2 and encrypted in TLS 1.3, which is why 1.3 captures show far less.

DNS. dns.flags.response splits query from answer, dns.id pairs them, dns.time is the response latency, and dns.flags.rcode != 0 finds failures. DNS over TCP happens for large responses and zone transfers, so filter dns and not udp.port == 53.

QUIC and HTTP/3. UDP 443. The handshake is partially encrypted from the first packet, so without keys you see connection IDs and packet types only. quic.long.packet_type distinguishes Initial, Handshake, and Retry.

ICMP. Errors quote the original packet's header, and Wireshark dissects the quoted part, so an ICMP type 3 packet shows the TCP header that triggered it. That is how you find a path MTU problem.

Checksum offload. Modern NICs compute checksums after the capture point, so outbound packets on the sending host show checksum incorrect. This is normal. Turn off the per-protocol Validate the … checksum if possible preference rather than chasing it.