Reading room · Case study · 21 October 2026

NEED_TIME on 904 responses: a DNP3 outstation the master never syncs

IIN1.4, NEED_TIME, is an outstation asking the master to set its clock. Most masters answer within seconds. When the bit stays up on every single response, the master is not doing its part, and every event timestamp from that outstation drifts a little further from the truth. This case shows one on a shared channel where the other outstations are synced correctly.

The pattern

Channel 10.0.1.18:20000 carries outstations 18, 19 and 21. For 18 and 19 the master runs the non-LAN time-sync procedure: a DELAY_MEASURE (function 23), then a WRITE of group 50 variation 1 with the corrected time. Their NEED_TIME clears. For outstation 21 the master never sends either: its time-sync task is disabled in the master configuration.

The result in the capture: all 904 responses from outstation 21 carry NEED_TIME. Its clock in this scenario drifts at 200 ppm, which is 0.72 seconds an hour, about 17 seconds a day. Over a commissioning window that is invisible; over a month it is enough to put a breaker trip in the wrong order against a protection relay that is synced.

Report chapter for outstation 21 with the finding that it asked for time sync in 904 responses and the master never synced it — The report chapter for outstation 21: the finding is written for you, with the count, and the verdict follows from it.

How to tell "never synced" from "sync refused"

Never synced: no function 23 or 24 and no WRITE of group 50 to that address anywhere in the capture. The fix is in the master: enable the time-sync task for that device, or the "sync on NEED_TIME" option.
Sync refused: the WRITE is there, but the response carries IIN2.0 (function not supported) or IIN2.2 (parameter error). The outstation does not accept that variation; LAN devices often expect the LAN procedure (function 24, RECORD_CURRENT_TIME, then group 50 variation 3).
Sync applied, flag back quickly: the clock cannot hold the time, or the outstation's own sync interval is very short. Compare how long the flag stays down after each sync.

Why a ranking catches it

A single response with NEED_TIME is normal. The useful signal is the ratio: the share of responses with the bit set and whether a time write followed. Ranking every outstation by it turns one flag among thousands of frames into a line at the top of a table.

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. Each outstation gets a finding when it asks for time and the master never syncs it. 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.