204 SYN retransmissions and no DNP3: an unreachable outstation in a capture
DNP3 analysis usually starts from DNP3 messages. An outstation that is switched off, or behind a firewall that drops its port, produces none, so it is invisible in any view built on decoded frames. The master is still trying, though, and every attempt is in the capture at the TCP layer.
What the master does
The master is configured for an outstation at 10.0.16.3:20000. It opens a TCP connection, waits up to 10 seconds, gives
up and tries again 20 seconds later. Nothing ever answers: no SYN/ACK, no RST. Each attempt is one SYN plus the operating system's own
SYN retransmissions.
Over 30 minutes that adds up to 68 attempts, 272 segments and 204 retransmissions, three per attempt, and zero bytes of DNP3. In a per-channel TCP table it is the worst line in the capture by far, while every channel that actually carries DNP3 shows zero retransmissions.
Silent drop or refusal
- Unanswered SYNs, no resets (this case): the host is down, unreachable, or a firewall drops the traffic. Check power, routing and firewall rules on the path.
- Immediate RST: the host is up but nothing listens on the port. The DNP3 service is stopped or configured on another port.
- Accepted, then FIN or RST before any DNP3: something answers the port but closes the connection, often an access list on the outstation that does not include the master's address.
A master log will usually say "connection timeout" for all three. The capture tells them apart.
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. Channels the master tried without ever getting DNP3 through are listed separately, with their attempts, repeated SYNs, resets and FINs. 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
- DNP3 event buffer overflow: losing events between polls
- Tuning a chatter filter from a DNP3 capture: 26 updates down to 6
- 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