What Is DNP3 File Transfer?

Back to Blog

How the File Object Moves Data

DNP3 file transfer is built on group 70, the file object, with several variations for the steps of a transfer: file command (open, close, delete), file status, file transfer (the data blocks), and file descriptors that list what is available. A transfer proceeds as a sequence: the master opens a named file on the outstation, then reads or writes it in blocks until done, then closes it. Each step is an ordinary DNP3 request and response, so file transfer rides the same application layer as everything else.

Because the file moves in blocks over a possibly slow link, a large transfer takes many exchanges. The block size and the link speed together set how long it takes, and the per-block structure means a failure can be retried at the block level rather than restarting the whole file. This makes DNP3 file transfer usable even on a constrained RTU link, where opening a separate connection just to fetch a config file would be impractical.

What File Transfer Is Good For, and Its Limits

The natural uses are remote configuration and diagnostics: pulling an outstation's configuration or event log back to the master, or pushing an updated config or firmware image out to a device at a site reachable only over DNP3. For a remote outstation with no separate management path, doing this over the existing link is a real convenience, and it keeps the file transfer under the same security controls as the rest of the DNP3 traffic.

The limits are speed and support. File transfer over a slow telemetry link is not fast, and it competes for bandwidth with the polling and event traffic on the same channel, so large files are best moved during quiet periods. Support also varies: not every outstation implements group 70, and the files, paths, and permissions available are device-specific. And because file transfer can move firmware and configuration, it is a sensitive capability that belongs behind authentication - a link running DNP3 Secure Authentication protects file operations along with control commands.

A Transfer Walked Through, Step by Step

Pulling a configuration file off an outstation follows a fixed shape regardless of vendor:

1. Request the file descriptor or directory listing first, if the device supports it, to confirm the exact name and reported size of what you are about to fetch.
2. Satisfy whatever authentication the outstation requires for file operations.
3. Send the file open naming the file and the mode - read, in this case. The outstation answers with a status code and, on success, a file handle.
4. Read sequential blocks against that handle, each carrying a block number, until the block flagged as last arrives.
5. Close the handle and check the status the outstation returns.
6. Verify the received file - size against the descriptor, and content sanity - before anything downstream consumes it.

The handle is the session, and it is worth respecting: a transfer abandoned mid-stream can leave the file held open on the outstation until the device times the handle out on its own implementation-specific schedule, which can block the next attempt. The block numbering is what makes the mechanism robust on bad links - a single failed block is retried by number rather than restarting the file from zero.

Fitting a Transfer Into a Live Channel

File blocks are not privileged traffic. Each one rides an ordinary application-layer request and response, subject to the same fragmentation rules as any large response - a block that exceeds what fits in one DNP3 fragment gets split and reassembled like anything else. On a shared or slow serial channel, that means a long transfer visibly stretches poll cycles and delays event delivery, so the operational habit is to schedule large pulls for quiet windows and to warn whoever watches the board that data may lag while the transfer runs.

Timeouts deserve deliberate attention before starting, not after the first failure. A master-side application timeout tuned for crisp LAN polling will fire mid-block on a slow radio path and abort a transfer that was actually proceeding, so the timeout must be sized for the slowest link the transfer crosses. Support is uneven at both ends: masters differ in whether file operations share the normal request queue or need a dedicated session, maximum block sizes are device-specific, and the only reliable guide is the documentation for both the master and the outstation.

When a Transfer Fails

Failures cluster into a few causes with distinct signatures. If the outstation does not implement group 70 at all, the open is rejected outright - the DNP3 device profile is where support is documented, and checking it beats experimenting. If the open returns a failure status, the usual suspects are the file name or path syntax, which is entirely vendor-specific, or a permissions and authentication mismatch for file operations specifically. If the transfer starts and then stalls, suspect a block size too ambitious for the link or a timeout firing mid-block.

When the status codes and documentation disagree with reality, look at the wire. A capture of the exchange shows the open request exactly as sent, the status the outstation actually returned, and where in the block sequence things stopped - the technique is the same as any protocol debugging session, covered in how to capture DNP3 traffic in Wireshark. Five minutes of capture routinely resolves what an evening of changing configuration guesses does not.

Frequently Asked Questions