Wireshark
The standard network protocol analyser. Captures live or from a file and dissects hundreds of protocols field by field, including industrial ones like Modbus/TCP, DNP3 and EtherNet/IP.
Wireshark is the de-facto network protocol analyser. It captures packets live or reads them from a file and dissects hundreds of protocols field by field, including the industrial ones like Modbus/TCP, DNP3 and EtherNet/IP that generic sniffers ignore.
What it is
Wireshark shows every packet to and from a device with full field-level decoding, so you can reverse a proprietary IoT protocol, watch a PLC's Modbus reads and writes, or spot plaintext credentials on the wire. Its power is the dissector: for a known protocol it labels every field by name (function code, register address, transaction ID), and for an unknown one it still gives you the raw bytes lined up against the hex. The CLI sibling tshark does the same headless, which is what you script and pipe. dumpcap is the minimal capture engine underneath both.
Why it matters
On the network side of a hardware assessment, the question is always "what is this device saying, and to whom?". Wireshark answers it: the cloud API a smart plug calls, the unauthenticated Modbus write that flips a coil, the MQTT topic a sensor publishes credentials on, the mDNS broadcast that reveals the whole product line. Because it decodes OT protocols natively, it is the first tool on any ICS/SCADA capture, and a saved pcap becomes shareable, replayable evidence.
How to use it
# Capture to a file, filtered at the capture layer (BPF syntax)
tshark -i eth0 -f "host 192.168.1.50" -w capture.pcap
# Read back and slice with a display filter, extract just the fields you want
tshark -r capture.pcap -Y "modbus" -T fields -e modbus.func_code -e modbus.reference_num
# Live decode of MQTT, following one topic
tshark -i eth0 -Y 'mqtt.topic contains "cred"' -T fields -e mqtt.msg
In the GUI the everyday moves are: type a display filter (modbus, mqtt, tcp.port == 502) in the bar, right-click a packet and Follow > TCP Stream to reconstruct a whole session in readable form, and Statistics > Conversations to see who talks to whom and how much.
Capture and display filters
The two filter languages are different and both matter. Capture filters (BPF, the -f flag: host, port, net) decide what hits the disk and cannot be changed after the fact. Display filters (-Y, the GUI bar: modbus.func_code == 6, ip.addr == 10.0.0.5 && tcp.flags.syn == 1) filter what you already captured and can be refined endlessly. Capture wide, then narrow with display filters, so you never lose a packet you did not know you needed.
Pitfalls
- On a switched network you only see your own traffic. To see another host's packets you need a SPAN/mirror port, an inline tap, or an ARP-spoof pivot; plugging in and expecting to see everything is the classic beginner mistake.
- TLS payloads are opaque unless you supply the keys (an
SSLKEYLOGFILE, or the server private key for RSA suites). For device-to-cloud HTTPS, pair Wireshark withmitmproxyto actually read the plaintext. - A huge
pcapwill crawl the GUI; pre-filter withtshark/dumpcap, or split witheditcap, before loading. - A capture filter is committed at capture time. Filter too tightly and the packet you later realise you needed was never written.
What it pairs with
Wireshark is the observation layer that feeds everything else. Use nmap first to find the services, then Wireshark to watch them talk; mitmproxy to decrypt the TLS it cannot; and for buses off the IP network, a usb-can-adapter (candump converted to pcap) or a logic-analyzer/sigrok capture to bring SPI, I2C or CAN traffic into the same field-by-field view.