Wireshark doesn’t just show you packets; it reveals the hidden conversations your network is having, often in ways that expose fundamental misunderstandings about how your applications actually work.
Let’s watch a real-time DNS query and response. Imagine you’re troubleshooting why a website is slow to load. You fire up Wireshark on your machine, select your primary network interface (say, eth0), and hit the "Start" button. You then navigate to example.com in your browser.
Here’s what you might see, filtered for DNS traffic (dns):
192.168.1.100 -> 192.168.1.1 DNS 128 Standard query A www.example.com
192.168.1.1 -> 192.168.1.100 DNS 128 Standard query response A www.example.com CNAME www.cloudflare.com
192.168.1.100 -> 192.168.1.1 DNS 133 Standard query A www.cloudflare.com
192.168.1.1 -> 192.168.1.100 DNS 133 Standard query response A www.cloudflare.com A 104.18.12.165
The first line is your machine (192.168.1.100) asking your local DNS resolver (192.168.1.1) for the IP address of www.example.com. The resolver, in turn, responds with a CNAME record, telling your machine that www.example.com is actually an alias for www.cloudflare.com. Your machine then makes another DNS query for www.cloudflare.com, and the resolver finally provides the IP address: 104.18.12.165.
This is the core problem Wireshark solves: visibility. You think your browser is just asking for www.example.com, but Wireshark shows you the multi-step choreography involving DNS resolution, CNAMEs, and ultimately, the IP address that will be used for the subsequent HTTP connection. You can click on any of these packets to see the full details in the lower panes: the Ethernet header, the IP header, the UDP header, and the DNS payload itself, broken down into its constituent fields.
The system is built around capturing raw network packets from a chosen interface, dissecting them according to various network protocols, and displaying them in a human-readable format. You control what is captured with capture filters (applied before packets are saved) and what is displayed with display filters (applied after packets are saved).
Let’s dive deeper. Suppose you’re troubleshooting a slow HTTP response. You’d filter for http and look for the TCP handshake (SYN, SYN-ACK, ACK) followed by your HTTP GET request and the server’s 200 OK response.
192.168.1.100 -> 104.18.12.165 TCP 74 51000 ? 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1 WS=256
104.18.12.165 -> 192.168.1.100 TCP 74 443 ? 51000 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 SACK_PERM=1 WS=256
192.168.1.100 -> 104.18.12.165 TCP 66 51000 ? 443 [ACK] Seq=1 Ack=1 Win=65535 Len=0
192.168.1.100 -> 104.18.12.165 TLSv1.2 1058 Client Hello
104.18.12.165 -> 192.168.1.100 TCP 1460 443 ? 51000 [ACK] Seq=1 Ack=1059 Win=262144 Len=0
104.18.12.165 -> 192.168.1.100 TLSv1.2 1460 Server Hello, Certificate, Server Key Exchange, Server Hello Done
192.168.1.100 -> 192.168.1.100 TLSv1.2 130 New Session Ticket, Change Cipher Spec, Encrypted Handshake Message
104.18.12.165 -> 192.168.1.100 TLSv1.2 1460 Change Cipher Spec, Encrypted Handshake Message
104.18.12.165 -> 192.168.1.100 HTTP 1460 HTTP Response: 200 OK
192.168.1.100 -> 104.18.12.165 TCP 66 51000 ? 443 [ACK] Seq=1307 Ack=1461 Win=262144 Len=0
Notice the TLS handshake happening after the TCP handshake. Wireshark dissects these layers. You can see the Client Hello, the server’s response, and then the actual HTTP request and response. If the HTTP Response: 200 OK is delayed significantly after the Encrypted Handshake Message from the server, you know the bottleneck is likely within the TLS negotiation or the server’s application processing, not the basic network connectivity.
The real power comes from reconstructing entire conversations. Right-click on an HTTP GET request and select "Follow" -> "TCP Stream". Wireshark will reassemble all the packets belonging to that TCP connection and show you the raw data exchanged, including the HTTP headers and body. This is invaluable for debugging application-level issues. You can see exactly what your client sent and what the server replied with, minus the network overhead.
Many users get bogged down by the sheer volume of packets. The trick is to use filters aggressively. For example, to see only traffic between your machine and a specific web server: host 104.18.12.165 and port 80 or port 443. Or to see only DNS queries originating from your machine: udp port 53 and ip.src == 192.168.1.100.
A common misconception is that Wireshark can decrypt SSL/TLS traffic out-of-the-box. It can’t, but it can decrypt it if you provide the server’s private key (or the session keys if you have them from another source like a browser). This is a powerful, albeit complex, feature for deep debugging. You’d go to Edit -> Preferences -> Protocols -> TLS and add your key log file or private key.
Once you’ve captured data, you can save it as a .pcap or .pcapng file for later analysis. This allows you to share problematic traffic with colleagues or analyze it on a more powerful machine. The .pcapng format is newer and supports more features, like storing multiple interfaces.
The next step after mastering basic capture and display filtering is understanding TCP sequence and acknowledgment numbers to diagnose retransmissions and out-of-order packets.