Who closed the DNP3 connection? FIN, RST and silence on a primary and backup path
"The RTU reconnected" is what most master logs say, and it is not enough to send anyone anywhere. The TCP side of the same capture says much more: which side ended the connection, whether it was an orderly close or an abort, and whether the next attempt was refused or never answered. Those are different faults, in different places.
The setup
RTU-30 has two paths: a primary at 10.0.8.30:20000 and a backup at 10.0.9.30:20000. The master uses the
primary, falls back to the backup when the primary fails, and comes back when it can. One hour of capture, three drops.
What the capture shows
| Time | Path | How the connection ended | Next attempts | Data gap |
|---|---|---|---|---|
| 00:15:00 | Primary | RST from the RTU | 2 SYN to the primary, both answered with RST; backup connects | 9.1 s |
| 00:30:00 | Backup | FIN from the RTU | 2 SYN to the backup, no answer at all; primary connects | 15.0 s |
| 00:45:00 | Primary | RST from the RTU | 2 SYN refused with RST; backup connects | 9.1 s |
| 01:00:00 | Backup | FIN from the master | end of capture | - |
Reading it
- RST from the outstation side is an abort: the process or the device dropped the connection without a goodbye. The two SYNs refused with RST right after say the host is reachable but nothing is listening on port 20000, so the DNP3 service itself was down for a few seconds. Look at the device: a restart, a crash, a watchdog.
- FIN from the outstation side is an orderly close: the outstation decided to end the session. Common causes are an idle or keep-alive timeout set on the device, a configuration change, or a gateway that closes sessions on its own schedule.
- SYN with no answer, retransmitted and timing out, is a path problem: nothing came back, not even a refusal. On the backup path that points at the radio or router, not at the outstation.
- FIN from the master at the end is the normal stop of the capture and not a fault.
Each drop also shows up in the DNP3 data: events that happened during the gap arrive in the first poll after the reconnect, 9 to 15 seconds late. That is the cost the SCADA sees, and the TCP side tells you where to send someone to fix it.
Try it on your own capture
ComputingSphere DNP3 shows the TCP session of every channel next to its DNP3 traffic: every reconnection with how the previous connection ended (FIN or RST, from which side, or no answer), SYN retries, retransmissions and the round trip. It only reads what already went over the wire. This capture is among the examples of every free account, to reproduce every number here; or upload your own: the Free plan covers 1,000 messages a month.