 | 1 | initial version |
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
