One trip, four rows: DNP3 unsolicited responses that are never confirmed
With unsolicited reporting, a DNP3 outstation does not wait to be polled: when an event happens it sends an unsolicited response with the CON bit set, and keeps the event in its buffer until the master answers with an application-layer CONFIRM. Only a confirm with the same sequence number and the UNS bit set releases those events. Anything else, and the outstation does what the standard tells it to: wait for the confirm timeout, then send the same response again.
The setup
Feeder recloser RTU 12 reports class 1 events unsolicited, with a 5-second confirm timeout and unlimited retries. The master was replaced last month. At 10:42:07 the breaker trips: one binary input event.
What the wire shows
| Time | From | Message | Seq |
|---|---|---|---|
| 10:42:07.120 | RTU 12 | UNSOLICITED_RESPONSE, FIR FIN CON UNS, 1 event (g2v2) | 5 |
| 10:42:07.180 | Master | CONFIRM, FIR FIN, UNS=0 | 5 |
| 10:42:12.130 | RTU 12 | UNSOLICITED_RESPONSE, same event, same timestamp | 5 |
| 10:42:17.140 | RTU 12 | UNSOLICITED_RESPONSE, same event, same timestamp | 5 |
| 10:42:22.150 | RTU 12 | UNSOLICITED_RESPONSE, same event, same timestamp | 5 |
- The master did answer, 60 ms later. The confirm is simply the wrong one: without UNS it confirms a solicited response, and there is none outstanding. The outstation ignores it.
- Every retry carries the same sequence number. That is how the master is supposed to recognise a repeat.
- The new master processes each one as fresh data, so the SOE shows the trip four times, five seconds apart, all with the same event timestamp.
- While the retries go on, the event stays in the outstation's buffer and anything new queues behind it. On a busy day this ends in an event buffer overflow.
What to fix
- The confirm. A confirm for an unsolicited response must have UNS=1 and echo its sequence number. This is a master setting or a master bug, not something to tune on the outstation.
- Duplicate detection. A master must discard an unsolicited response that repeats the last sequence number it saw from that outstation, and still confirm it.
- Retry limit. Unlimited retries every 5 s hide the problem for weeks. A limit, followed by an alarm, makes it visible.
- Look for the pattern after any master change: repeated unsolicited responses with an identical sequence number and payload.
Try it on your own capture
ComputingSphere DNP3 decodes every message of a pcap, per outstation, with the application control flags (FIR, FIN, CON, UNS) and sequence numbers shown on each one, so a confirm without UNS or a run of identical retries is visible without reading hex. It only reads what already went over the wire. The Free plan covers 1,000 messages a month.