Modbus TCP Wireshark Analysis: Capture & Debug Modbus Traffic

When a Modbus TCP integration misbehaves — a PLC that won't connect, a slave that answers some requests but not others, an SCADA tag stuck at a stale value — the fastest way to find out what's actually happening on the wire is to capture it in Wireshark. This guide covers the capture setup, the display filters that matter, and how to read a Modbus request/response pair well enough to diagnose the common failure modes.

Setting Up the Capture

• Capture on the network interface that carries the Modbus TCP traffic — if the master and slave are on different subnets through a switch, you may need to capture on a SPAN/mirror port or run the capture directly on the master or slave host.
• Wireshark's Modbus/TCP dissector decodes traffic automatically on port 502, the IANA-registered default. If the device uses a non-standard port (1502, 5020, 8502, and similar are common), right-click any packet on that port and choose Decode As…, then set the protocol to Modbus/TCP so every packet in the capture gets decoded, not just raw TCP bytes.
• If you only care about Modbus traffic, set a capture filter of tcp port 502 (or your device's actual port) before you start, so the capture buffer doesn't fill up with unrelated traffic on a busy network.

Display Filters That Matter

Filter	What it shows
modbus	Every decoded Modbus TCP packet, request and response
modbus.func_code==3	Only Read Holding Registers requests/responses (swap in 1, 2, 4, 6, 15, 16 for other function codes)
modbus.func_code > 0x80	Exception responses only (function code + 0x80) — a fast way to find every failed request in a capture
tcp.analysis.retransmission && tcp.port==502	TCP-level retransmissions on the Modbus port — a strong signal of an unstable link or an overloaded slave
tcp.flags.syn==1 && tcp.flags.ack==0	Outbound connection attempts — if you never see a matching SYN-ACK, the slave IP/port isn't reachable at all

Reading a Request/Response Pair

Every Modbus TCP frame starts with an MBAP (Modbus Application Protocol) header containing a Transaction Identifier, a Protocol Identifier (always 0 for Modbus), a length field, and the Unit Identifier (the slave address, relevant when the TCP connection is bridged to a serial RTU segment behind a gateway). Wireshark's dissector surfaces all of these as named fields and labels each frame Query (master → slave) or Response (slave → master).

To confirm a specific request actually got answered, filter to its function code, then match the Transaction Identifier between a Query frame and the following Response frame with the same ID. If you see Query frames with no matching Response and no TCP retransmission, the slave is silently ignoring the request — check its unit ID, register address range, and function-code support before assuming a network problem.

Spotting Exception Responses

A Modbus exception response reuses the request's function code with the high bit set (adds 0x80), followed by a one-byte exception code: 01 Illegal Function, 02 Illegal Data Address, 03 Illegal Data Value, 04 Slave Device Failure, and a handful of others less commonly seen. A Read Holding Registers request (function code 0x03) that the slave rejects comes back as function code 0x83. Wireshark labels these directly in the packet detail pane and in the Info column, so you don't need to hand-decode the hex — filter modbus.func_code > 0x80 to pull every exception in a capture at once. See our Modbus exception codes guide for what each code actually means and how to fix the underlying cause.

A Practical Debugging Workflow

When a real device's behavior is in question, it helps to have a known-good baseline to compare against. Run ModbusSimulator as a slave with the same register map and function codes the real device is supposed to support, capture traffic against the simulator, and compare it side-by-side with the capture from the suspect device. Differences in function codes, unit IDs, exception responses, or missing replies point directly at where the real device (or the master's configuration) diverges from spec — without needing physical access to the field device at all.