What Wireshark adds
Wireshark is a protocol analyzer that decodes captured packets and exposes fields from hundreds of protocols. Its troubleshooting value is that it shows what crossed the capture point rather than forcing you to infer behavior only from application errors or device summaries.
A capture can answer whether a request left the host, whether a response returned, which addresses and ports were used, whether TCP retransmitted, what DNS answer arrived, or whether ARP/Neighbor Discovery completed.
Choose the right capture point
A packet capture is only evidence about the location where it was taken. Capturing on a client proves what the client sent or received; capturing on a server proves what reached the server. SPAN ports, TAPs, virtual switches, cloud mirroring, and host captures all observe different parts of the path.
If the question is whether a firewall forwards traffic, captures on both sides can be more useful than a single large capture. Record interface, direction, topology, and timestamps so the evidence remains interpretable later.
Capture filters vs display filters
Capture filters decide which packets are collected and use BPF-style syntax. Display filters operate after capture and use Wireshark's own field-oriented syntax. They are different languages and are not interchangeable.
Use capture filters to reduce volume when the capture would otherwise be too large. Use display filters for flexible analysis because you can change them repeatedly without losing packets that were already recorded.
Basic display filters
Examples include ip.addr == 192.0.2.10, tcp.port == 443, dns, arp, icmp, and ipv6. Filters can combine conditions with logical operators and can reference decoded protocol fields such as DNS response codes or TCP flags.
Start broad enough to preserve context, then narrow by endpoints, conversation, protocol, error condition, or frame number.
Basic capture filters
BPF capture filters commonly use expressions such as host 192.0.2.10, net 192.0.2.0/24, port 53, or tcp port 443. They reduce capture volume before Wireshark stores packets.
A filter that is too restrictive can remove the very evidence you need, such as ARP, DNS, ICMP errors, or a second connection. When storage allows it, capture a little wider and filter later.
How to read a packet
Read from lower to higher layers: frame metadata, Ethernet headers, VLAN tags if present, IP source and destination, transport protocol and ports, then application fields. Check lengths, checksums with caution, flags, sequence numbers, and timing relative to surrounding frames.
Do not inspect packets in isolation when the protocol is conversational. The meaning of a TCP segment or DNS reply often depends on the frames before and after it.
TCP: handshake, retransmissions, and close
A normal TCP connection begins with SYN, SYN-ACK, and ACK. If SYN packets repeat without a SYN-ACK, investigate reachability, policy, server listening state, and return path. A reset indicates an explicit rejection or connection termination, but you still need to identify which endpoint or middlebox sent it.
Retransmissions, duplicate ACKs, and out-of-order indications can reveal loss or reordering, but Wireshark's analysis is based on what the capture point observed. Missing packets in the capture are not always missing on the network.
DNS in Wireshark
Filter on dns and pair queries with responses using identifiers, addresses, and timing. Inspect the queried name, type, response code, answer records, TTL, and whether the client retries or changes transport.
A packet capture can distinguish no response from NXDOMAIN, SERVFAIL, a valid unexpected answer, or a referral. It can also show whether the client is querying a different resolver than you assumed.
ARP and Neighbor Discovery
ARP resolves IPv4 neighbors on the local link, while IPv6 uses Neighbor Discovery with ICMPv6. Repeated unanswered ARP requests or Neighbor Solicitations are strong evidence of a local reachability problem.
Look for duplicate-address symptoms, gratuitous ARP behavior, Neighbor Advertisements, and router discovery when diagnosing gateway or first-hop problems.
Follow Stream and conversations
Follow TCP/UDP/HTTP or other stream features reconstruct a conversation from multiple packets and make request/response relationships easier to read. Conversation and endpoint statistics summarize traffic by address and port.
These views are useful for navigation, but return to individual frames when timing, retransmission, fragmentation, or packet-specific flags matter.
Expert Information and statistics
Expert Information highlights conditions such as retransmissions, malformed fields, protocol warnings, or unusual sequences. Statistics menus expose protocol hierarchy, conversations, endpoints, I/O graphs, and other summaries.
Treat automated flags as clues, not verdicts. A retransmission warning can result from capture loss, and an unusual protocol sequence may be valid for the application.
What you can see when traffic is encrypted
Encryption hides application payload but does not make the flow invisible. You can still observe endpoints, ports, packet sizes, timing, TCP behavior, and often handshake metadata. Depending on the protocol and environment, authorized key material may allow deeper decryption.
Even without decryption, transport evidence can prove whether a session was established, whether packets were retransmitted, and where a connection was reset.
Privacy and handling captures
PCAP files may contain internal topology, IP addresses, hostnames, user identifiers, authentication exchanges, and sometimes plaintext application data. Handle them as sensitive operational data, limit capture scope, and redact or sanitize before sharing externally.
Capture only what you are authorized to inspect. Packet analysis is a troubleshooting tool, not a reason to bypass privacy or security controls.
A practical analysis workflow
Start with a precise question and choose the capture point. Reproduce the issue once, note the exact time, stop the capture, and save the original file. Apply broad filters first, identify the relevant endpoints and conversation, then inspect protocol-specific details.
Build a timeline: request, intermediate behavior, response or timeout. Write down the observation that supports each conclusion so another engineer can reproduce your analysis.
Compare captures at two points
Two synchronized captures can isolate where behavior changes. If a packet exists before a firewall but not after it, inspect policy and translation. If it leaves a server but never reaches the client-side capture, investigate the return path between those points.
Accurate timestamps help, but sequence numbers, identifiers, and payload characteristics can also correlate the same flow across captures.
Documentation and next step
The Wireshark User's Guide and display-filter reference document current syntax and features, while protocol standards explain the fields Wireshark decodes. Combine both with your network topology and device logs.
Once you can observe flows confidently, continue to the Network Security cluster, where ACLs, firewalls, VPNs, AAA, and Layer 2 controls explain many policy-driven outcomes seen in packet captures.