DNP3 event buffer overflow: losing events between polls
An outstation stores events (changes with timestamps) in a buffer per class until the master reads them. If changes arrive faster than the master collects them, the buffer fills, the oldest or newest events are discarded, and the outstation sets IIN2.3 EVENT_BUFFER_OVERFLOW. The data that reaches the SCADA afterwards is still current, but the sequence of events is not complete, which is exactly what a post-fault analysis needs.
The setup
Outstation 4 on 10.0.3.4:20000 has 30 binary inputs and a class 1 buffer of only 20 events. Every 5 minutes a disturbance
toggles all 30 inputs twice within 2 seconds: 60 events. The master polls class events every 30 seconds.
Sixty events into a 20-event buffer, with up to 30 seconds before the next poll, cannot fit. Each burst overflows.

What the capture shows
- IIN2.3 on 5 responses, 7% of the outstation's responses: one per burst, on the first poll after it.
- Event delay median 28 seconds: the time between an event's own timestamp and its arrival is roughly the poll interval, because nothing reports it sooner.
- No retries, no unanswered requests, healthy TCP. This is a sizing problem, not a communication problem.
What to change
- Poll events faster, or enable unsolicited reporting for class 1, so bursts drain while they happen.
- Enlarge the buffer if the device allows it; size it for the worst burst, not the average rate.
- Find the noisy point: often one chattering input fills the buffer for everyone. A chatter filter at the source or a deadband on analogs cuts the event rate (see tuning a chatter filter from a capture).
- After an overflow, the master should run an integrity poll (class 0, 1, 2, 3) to resynchronize its static values.
Try it on your own capture
ComputingSphere DNP3 decodes a pcap once, splits it per channel and per outstation, and ranks the outstations worst first with the same numbers used here. It only reads what already went over the wire. Overflow is reported as a share of each outstation’s responses, next to the event delay. This capture is among the examples of every free account, to reproduce every number in this post; or upload your own: the Free plan covers 1,000 messages a month.
More cases from the same capture
- One silent outstation on a multidrop line: finding it in a DNP3 capture
- NEED_TIME on 904 responses: a DNP3 outstation the master never syncs
- Why a DNP3 SELECT/OPERATE fails: timeout, unsupported point and local control
- Tuning a chatter filter from a DNP3 capture: 26 updates down to 6
- 204 SYN retransmissions and no DNP3: an unreachable outstation in a capture
- Self-healing on stale data: three DNP3 problems a FLISR scheme should not meet
- The substation GPS that overwrote the master: DNP3 events an hour in the future