Wireshark
Description
The first time I opened Wireshark, I was twenty years old, sitting in a university computer lab, with no idea what I was looking at. My networking professor had told us to capture five minutes of traffic and “describe what you see.” I clicked the green shark fin icon, chose my Ethernet interface and watched as hundreds of lines began scrolling past faster than I could read. Each line was a packet — a tiny piece of data leaving or arriving at my machine — and each one had a source address, a destination address, a protocol, and a length. Five minutes yielded more than twelve thousand packets. I had opened Chrome once and checked my email.
That was it. Twelve thousand packets for one browser tab and an inbox with three unread messages. I sat there realizing that my computer had been having conversations I knew nothing about — DNS lookups, TCP handshakes, TLS negotiations, ARP broadcasts, SSDP discovery, something called NBNS that I had to Google later. It was like lifting the hood of a car for the first time and finding that the engine is much, much more complicated than the steering wheel ever led you to believe.
That was 2013. I have used Wireshark on and off ever since, and the feeling has never quite left me – the slightly uneasy feeling of seeing exactly how much your machine communicates without your explicit instruction, combined with the fascination of understanding how it all actually works at the wire level.
Wireshark began as Ethereal, developed by Gerald Combs in 1998 when he was working at an internet service provider and needed a tool to debug network problems. He changed it to Wireshark in 2006 because of trademark problems with his former employer. It is open source, totally free, runs on Windows, Mac, Linux, and several other platforms, and is the de facto standard network protocol analyzer. If you are in the IT field, work in network engineering, cybersecurity, or software development, you either use Wireshark or know someone who does. It is not optional knowledge in those fields. It is foundational.
The installation is not painful. On Windows, the installer includes Npcap — the packet capture driver that allows Wireshark to see raw network traffic — and you are up and running in less than three minutes. On Linux, it is typically one package manager command. On macOS, a DMG drag and drop. No account creation, no license key, no telemetry opt-in, no trial period. You install it and it works. After years of seeing software that used installation as an opportunity to sell software, Wireshark’s quiet and efficient installation seems almost disrespectful to the norm.
The interface, though. The interface is where the new users push through or give up. The main window of Wireshark is split into three panes. The top pane is the packet list — all the captured packets on one line, color-coded by protocol. The middle pane is the packet detail — a tree view that breaks down the selected packet layer by layer, from the Ethernet frame to the IP header to the TCP segment to the application payload. The bottom pane is the raw hex dump — the actual bytes, displayed in hexadecimal on the left and in the right in ascii.
If you know what you are looking for, this is an efficient and information dense layout. If you do not know what you are looking for, it looks like the Matrix. There is no onboarding wizard. There is no “start here” guide within the application. Wireshark assumes you know what a protocol is, what a packet is and why you would want to see one. If you do not, the learning curve is not steep — it is vertical for the first few hours.
But there is the thing about wireshark that makes it worth the pain – once you learn the display filters, the whole application opens up. Display filters are how you tell Wireshark to show you only the packets you care about. http shows only the traffic from the http protocol. ip.addr == 192.168.1.1 shows only the traffic to or from a specific device. tcp.port == 443 shows only the https connections. dns && ip.src == 10.0.0.5 shows only the DNS requests from a specific machine.
The filter language is deep and precise — you can filter by packet length, by TCP flags, by the content of specific bytes at specific offsets, by whether a TLS certificate contains a certain domain name. I once tracked down a wayward IoT camera that was sending data to a server in a country it had no business sending data to. The filter was ip.src == 192.168.1.47 && !(ip.dst == 192.168.1.0/24) — show me everything leaving the camera that is not going to my local network. Fourteen packets every two minutes, all to the same IP address in Shenzhen. I took the camera out of the plug and never plugged it back in.
That story is just what Wireshark is for. Not for casual users. Not for people who want a dashboard with green checkmarks telling them their network is healthy. Wireshark is for the time when something is wrong and you need to see exactly what is going on on the wire. A website is not loading — is DNS resolving? Is the TCP connection finishing up? Is the server responding back with an error? An application is slow — is there packet loss? Are retransmissions occurring? Is the TCP window scaling correct? A device is acting suspicious — where is it sending data? How often? How much? These questions cannot be answered by any monitoring dashboard as precisely as they can be answered by looking at the actual packets. Wireshark is not an interpreter. It does not guess. It shows you what exactly happened, and in the order it happened, down to the microsecond.
The protocol support is astounding. Wireshark has the ability to dissect more than 3,000 protocols. Not just the common ones — TCP, UDP, HTTP, DNS, DHCP — but industrial protocols like Modbus and DNP3, VoIP protocols like SIP and RTP, database protocols like MySQL and PostgreSQL wire format, IoT protocols like MQTT and CoAP, automotive protocols like CAN bus. If data is moving across a network, and someone has written a dissector for it, Wireshark can read it. I once used it to debug a Modbus TCP connection between a PLC and a SCADA system in a small factory.
The control engineer had been troubleshooting for 2 days. I took a traffic capture for ten minutes, filtered for Modbus and found that the PLC was responding with exception code 0x02 — illegal data address — on every third request. The register map in SCADA configuration had a typo. One wrong number in one field. Two days of down-time because of a digit. Wireshark located it in ten minutes because it could show me the exact Modbus response codes that the PLC was sending.
The “Follow TCP Stream” feature is one of the most useful things in any software I have ever used. You right-click on any packet in a TCP connection and select “Follow TCP Stream” and Wireshark reconstructs the entire conversation between client and server in a readable window. For unencrypted protocols, this means that you can read the entire request and response of the entire http request / response, the entire email exchange in smtpd, the entire ftp command sequence.
I used this in a university project to see exactly what headers my browser was sending to a web server — user agent, cookies, referrer, accepted encoding — and it was the first time I had a real understanding of how the web protocol — or rather, the web server — worked. Not from a textbook. From seeing the actual bytes my machine sent, and the actual bytes the server sent back. There is no substitute for that kind of understanding.
Of course, in 2026, most of the traffic worth looking at is encrypted. HTTPS is everywhere. TLS 1.3 has made passive decryption almost impossible. You cannot read the contents of an encrypted connection by just capturing packets — you see the TLS handshake, you see the certificate exchange, and then you see encrypted application data that might as well be random noise. Wireshark is able to decrypt TLS traffic if you supply the session keys, which browsers can write to a log file by setting an environment variable called SSLKEYLOGFILE.
I use this regularly for debugging web applications — set the variable, open Firefox, capture traffic, and Wireshark automatically decrypts the HTTPS sessions using the key log. It works perfectly and shows the entire exchange of the http/2 or http/3 below the encryption. But this only works for traffic from your own machine where you have control over the browser. For traffic from other devices on the network, encryption means that Wireshark displays to you the envelope, but not the letter inside.
Performance has been a nagging problem with big catches. Wireshark loads the entire capture file into memory, which means that a 500 MB pcap file will use a lot of RAM and take a few seconds to open. A 2 GB capture — which is easy to generate on a busy network in a few minutes — can make the application sluggish and applying complex display filters on a large file can freeze the interface for ten to fifteen seconds. The command-line companion tool, tshark, is more graceful with large files because it does not need to render a GUI, and for serious analysis on multi-gigabyte captures, most people I know use tshark to pre-filter the data and then open the smaller result in Wireshark.
This is a limitation of the workflow that has been in existence for years and that the development team has improved incrementally but never fully solved. Compared to commercial alternatives such as Omnipeek or Savvius, the large file handling in Wireshark is slow. Compared to the fact that those tools cost thousands of dollars and Wireshark costs zero, I can live with a ten second filter delay.
The statistics menu is criminally underutilized by most people, including me for the first several years. Protocol hierarchy shows you a breakdown of all traffic by protocol — instantly answering the question “what is using my bandwidth.” Conversations illustrates each pair of communicating endpoints ranked by data volume. IO Graphs will plot the traffic over time and can overlay multiple filters to compare the patterns.
Expert Information flags potential problems — retransmissions, out-of-order packets, duplicate ACKs, zero window events — and presents them in a table that is sorted. I have resolved more performance problems using the Expert Information than any other way. A network that appears fine on the surface will have hundreds of TCP retransmissions hiding underneath, each of them adding milliseconds of latency that add up to the “it just feels slow” complaint that no ping test will capture.
I should mention the ethical dimension as it is easy to capture traffic that is not yours with Wireshark. On a shared network — a coffee shop, a university, a poorly segmented corporate LAN — if you put your interface in promiscuous mode, Wireshark will see traffic from other devices. This was how passwords were stolen before encryption was common. This is why Wireshark has a reputation in some quarters as a “hacking tool,” which is like calling a kitchen knife a weapon — technically accurate, fundamentally misleading. Wireshark is a diagnostic tool. It captures packets. What you do with those packets is a decision that the software does not make for you. In most jurisdictions it is illegal to capture traffic on a network that you don’t own or have explicit authorization to monitor. Wireshark will not prevent you from doing this. It will not stop you from cutting yourself with a kitchen knife either. The responsibility is yours.
I still open Wireshark at least once a month. Sometimes to debug a connection problem. Sometimes to check whether a firewall rule is functioning properly. Sometimes out of pure curiosity — I will take five minutes of idle traffic from my home network just to see what my smart devices are up to when they think nobody is watching. The answer is always: more than you would think. The smart TV phones home to three different analytics services. The thermostat communicates with its cloud server every ninety seconds. The robot vacuum sends telemetry which I have never been able to fully decode. Wireshark does not correct any of this. It just shows it to you. And sometimes, knowing is the whole point.
It is ugly. It is intimidating. The learning curve will kick you in the face for the first few weeks. But Wireshark is the single most educational piece of software that I have ever used. Nothing taught me more about how networks actually work than trying to see my own packets as they moved across the wire. Every networking textbook I read in university made more sense after I saw the concepts in a live capture. Every “it just works” technology — Wi-Fi, DNS, HTTPS, streaming video — became less magical and more mechanical when I could see the individual pieces. Wireshark does not make networking easy. It makes networking visible. And visibility, once you have it, is something you never want to give up.
