I have a device (lets call it MovaColor) which communicates with clients connected via modbus tcp. The clients make read/write operations to the movacolor. Client 1 is plc based hardware (B&R PP41), client 2 is IPC based implemented in Labview with modbus library running on windows XP (IPC is also from B&R APC 810). I have reproducible communication problems :
When client 2 (IPC) communicates with movacolor then reading registers is without problem (after connection), but after writing once, the next read response is fragmented, an I get an an error message from client 2, that the network connection was closed by the peer. Than, after few seconds, there is also an RST frame.
In comparison to that I tested the communication between movacolor and client 1 (plc based). Also with read/write requests. Reading from the device is no problem, but after writing once, the next read response is fragmented as in the situation above, but does not lead to connection reset. I uploaded an pcap for the Movacolor - Client 1 communication also.
I compared both traces and found that client 2 has set the don't fragment bit and client 1 does not. What does it mean ?. My knowledge is kind of limited here. I ask myself why the fragmentation does occure at all, even if it is only 70 byte. I asked the OEM of the movacolor for the MTU size of the controller unit, unfortunately it is not known.
Any help in this issue is higly appreciated.
asked 27 Feb '14, 01:39
edited 27 Feb '14, 23:49
In the capture for client 2, in frame 26 the remote device sends back an incorrect response to the Write Multiple Registers request sent in frame 24. The erroneous response includes the byte count and data that were transmitted in the request (02 00 01). If you have Modbus TCP Reassembly turned on, this then messes up the dissection of the next response in frame 29.
Regardless of the above I can see no reason in the dissected Modbus traffic for the remote device to then send the RST in frame 31. It does send the RST after a delay of 3 seconds so I wonder if the client device is confused by the erroneous response and stops communicating and the remote device times out.
In the capture for client 1, the client seems to ignore the erroneous response and so communication proceeds as expected.
Purely conjecture, but I suspect that client 1 is draining the receive stream of all data after reading the expected response, before transmitting the next query and so handles the erroneous response. Client 2 probably doesn't do this and after the subsequent query response is coalesced with the erroneous trailer the client is confused and stops communicating.
answered 05 Mar '14, 04:22