Revision history [back]

The capture was made using an older version of Wireshark (3.2.7) on a Windows 10 (1803) system. I'm guessing that the capture was made on the endpoint (1.19) simulating the Modbus device due to the very small (or 0) time delays between the Modbus query and the response. When running experiments like this it helps to capture at both ends, or even better off-machine e.g. with a tap or a span or mirror port from the switch(es).

I'm assuming that as stated in the 6 second gan between frames 9 & 10 the link between the 2 switches was disconnected and then reconnected, I'm wondering if there has been some other traffic that hasn't been captured, e.g. ICMP?

The other thing that seems a little odd is that the Modbus client (1.17) is querying the Modbus device very quickly with no delay between the previous response and the next request and then suddenly jumps to a 6 second delay as the link is disconnected?

The basic issue is that the Modbus query in Frame 10 hasn't been acknowledged (relative seq. #49) by the Modbus device and the Modbus client should timeout and retransmit it, especially when notified by the duplicate ACK messages from the Modbus device that only acknowledge relative seq. # 37.

Questions for @soapy

1. How was the capture made?
2. What capture filter, if any was used?
3. Why the 6 second delay in the query in frame 10?
4. Can the capture be done again, this time at both ends if possible and with an up to date version of Wireshark so any capture filters are recorded?
5. Is the Modbus device a real PLC or a simulated device?