Link-layer confirms over TCP: twice the DNP3 frames and retries for nothing
Every DNP3 frame has a data link header, and its function code decides whether the other side must acknowledge it. CONFIRMED_USER_DATA (function 3) asks for a link-layer ACK for every frame; UNCONFIRMED_USER_DATA (function 4) does not. Link confirms come from serial and radio links, where nothing else guarantees that a frame arrived. Over TCP, delivery is already guaranteed, and IEEE 1815 recommends unconfirmed user data. Configurations copied from a serial RTU sometimes keep the old setting.
The setup
A pumping station RTU on a 4G router, polled every second for 30 minutes. Both master and outstation use confirmed user data, with a 1-second link confirm timeout copied from the serial channel the station used before. The 4G round trip is usually around 120 ms, with spikes above 1.4 s a few times an hour.
What the capture shows
| 30 minutes, one RTU | Confirmed user data | Unconfirmed user data |
|---|---|---|
| Frames on the wire | 7,200 | 3,600 |
| Link retries | 41 | 0 |
| Link resets (RESET_LINK_STATES) | 6 | 0 |
| Requests the outstation saw twice | 9 | 0 |
- Every request and every response is followed by an ACK frame: twice the frames, and on a metered 4G contract, more traffic for no gain.
- When a round trip passes the 1-second link timeout, the sender repeats the frame although TCP has already delivered it. The receiver now has it twice.
- After a few failed confirms the link resets its state, and the next exchange starts with RESET_LINK_STATES. In the master's logs this looks like an unstable link; the TCP connection was never interrupted.
What to set
- Use unconfirmed user data on both ends of every DNP3 over TCP link. Reliability belongs to TCP here, and the application layer still has its own confirms where they matter (events).
- If a device cannot turn link confirms off, set the link timeout above the worst round trip of the network, not the serial value.
- When a TCP link "has retries", check first whether they are TCP retransmissions or DNP3 link retries. They have different causes.
Try it on your own capture
ComputingSphere DNP3 decodes every frame of a pcap down to the data link layer, with its function code, and shows the TCP session of the same channel next to it, so link retries and TCP retransmissions are not confused. It only reads what already went over the wire. The Free plan covers 1,000 messages a month.