How to Capture and Read DNP3 Traffic in Wireshark
Half the DNP3 arguments in a troubleshooting call - is the outstation sending events, is the master confirming, whose timeout fired - are settled in five minutes by a packet capture. Wireshark decodes DNP3 natively, down to function codes, object headers, and the IIN bits, so the skill worth having is not decoding frames by hand but capturing in the right place and knowing which fields answer which question. That is what this guide covers.
DNP3 Wireshark Capture in one line: To capture DNP3 in Wireshark, capture at a point that sees the master-outstation TCP session - a SPAN port, a tap, or the master host itself - filter with the dnp3 display filter (capture on the configured port, conventionally 20000), and read each response's function code, object headers, and internal indication bits. Most faults announce themselves: empty responses to event polls, missing confirms, or an IIN bit nobody was watching.
What You Need
You need Wireshark on a machine positioned to see the traffic, and a capture point: a mirror or SPAN session on the switch carrying the master's traffic, an inline tap, or - simplest where acceptable - Wireshark running on the master or gateway host itself. On segmented OT networks, involve whoever owns the switches early; a mirror port is a small ask with lead time and an impossible one mid-incident. Sites that maintain continuous capture infrastructure, as described in full packet capture and PCAP retention, skip this scramble entirely.
Know the session parameters before you start: the outstation's IP, the TCP port in use (20000 by convention, but confirm), and roughly when the misbehavior occurs. For serial DNP3 there is no Wireshark tap point - use the gateway's or master's own communication log, or a serial line analyzer, and apply the same reading skills to its decode.
Capture and Filter the Session
Start the capture with a capture filter narrowing to the outstation's address and port, so an hour of waiting for an intermittent fault does not produce an unmanageable file. Once traffic is flowing, apply the dnp3 display filter and confirm Wireshark is dissecting the frames - you should see function codes and object headers in the detail pane. If the deployment uses a non-standard port, tell Wireshark to decode that port as DNP3 and the dissection appears.
Capture through at least one full cycle of the behavior you are chasing: a couple of poll rounds for a polling issue, an outstation restart for a handshake issue, a control attempt for a control issue. Save the raw capture before experimenting with filters - the pcap file is the evidence you will attach to a vendor ticket, and an unfiltered original preserves context you did not know you needed.
Read the Exchange Like a Conversation
Follow one request-response pair at a time. The master's request carries a function code - read, write, select, operate, enable unsolicited - and object headers saying which data it wants; the outstation's response carries the data and, critically, the two internal indication octets present in every response. Read those IIN bits on every response you examine, because they are the outstation's own running commentary: restart, need time, buffer overflow, parameter error - the full decoding is in the DNP3 IIN field explainer.
A healthy polling cycle has a recognizable rhythm: request, response with data, confirm when events were delivered, quiet until the next poll. Deviations map to causes: an event poll answered by an empty response says the outstation has nothing to report, which - if the field disagrees - moves the problem to event generation, the territory of events not arriving. The same events retransmitted every cycle says confirms are not landing. A response that never comes says link or device, not configuration.
Verifying the Result
A capture is verified when it demonstrably contains the failure: the timeout firing, the empty response, the rejected control, alongside timestamps that let you measure the intervals people have been guessing about - actual round trips, actual select-to-operate gaps, actual confirm latency. Measured intervals end arguments that adjectives sustain indefinitely; slow becomes a number and the number either exceeds the configured timeout or it does not.
If the capture shows only healthy traffic, that is a result too: the fault is not on this segment during this window, and attention moves to the other side of the gateway, to the serial leg, or to a different time of day. Move the capture point or the capture window deliberately rather than concluding the problem is unreproducible - it reproduces somewhere you are not yet looking.
Common Mistakes
The most common mistake is capturing on the wrong side of an address translation or gateway and concluding traffic is absent when it is simply elsewhere: NAT boundaries, VPN tunnels, and protocol converters all create segments where the conversation looks different or does not appear at all. Sketch the actual path first and choose the capture point against the sketch, not the network diagram from five years ago.
The reading mistakes: ignoring the IIN bits (the answer is printed on every response and routinely unread), mistaking link-layer confirmations for application confirms when diagnosing event-clearing problems, and trusting capture timestamps across two machines whose clocks disagree - measure intervals within one capture, not between two. And treat captures as sensitive operational data: they contain your addressing, point maps, and control patterns, so store and share them accordingly.
Frequently Asked Questions
Can Wireshark decode DNP3 Secure Authentication traffic?
The exchange itself is visible - challenges, responses, and the authentication objects decode like any other DNP3 traffic, because Secure Authentication signs rather than encrypts. What you can read is that authentication is happening and whether it succeeds; the keys and HMAC contents are opaque by design. If the deployment wraps DNP3 in TLS, the capture shows only the encrypted stream unless you capture inside the tunnel endpoint.
How do I capture serial DNP3?
Wireshark needs packets, and a serial line has none - so either use a hardware serial analyzer or tap, or capture at the nearest device that logs the serial exchange: most gateways and many masters can log raw frames on the serial port. The analysis skills transfer directly, since the function codes, objects, and IIN bits are identical regardless of transport.
Will capturing DNP3 traffic disturb the live system?
Passive capture from a SPAN port or tap adds nothing to the OT traffic and is safe by construction; capturing on the master host costs only local resources. What deserves caution is generating traffic - never point an active DNP3 test tool at a production outstation casually, and coordinate mirror-port configuration with the network owner, since a misconfigured span can burden a switch. Observation is safe; interrogation is a change.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- Overview of DNP3 (IEEE Std 1815) - DNP Users Group
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.