Search code examples
wiresharkmodbusmodbus-tcp

Can there be several application layer (Modbus) PDUs in one TCP segment?

I'm analyzing some captured packets and see that for some of the packets, Wireshark displays the image below, which appears to contain several Modbus PDUs in the one TCP segment. I have searched online for answers but can't see this behavior anywhere I looked. From what I'm reading, Wireshark re-assembly gathers the different TCP segments, and so it appears this can't be reassembly.

My question is: is this behavior (i.e. having several Modbus PDUs in one TCP segment) normal and expected? If not, what is causing this problem? Is this an issue with Wireshark?

Capture link to fullsize image

Solution

  • Yes - Modbus TCP runs at the application layer and supports multiple simultaneous transactions over a single connection (see page 10 of the spec). So sending:

    00 01 00 00 00 06 01 03 00 00 00 01 00 02 00 00 00 06 01 03 00 01 00 01

    is fine (this is 2 x "Read Holding Register" commands - note the different transaction identifiers). If this is sent at the same time it's likely the two commands will be sent out in the same packet. While this is supported (by some devices!) its not something I see often (unless performance is key its easier to process the response before sending another request).

    However I don't think this is what is happening in your case. The lines you are highlighting are flagged TCP Retransmission so I'm assuming there was a connectivity issue. You can also see this in the 1s gap between the retransmitted packed and the previous request (it looks like queries are being sent every 300ms).

    862.493794
    862.805685 - 0.3s gap
    863.117588 - 0.3s gap
    864.232576 1st retransmission - 1.1s gap

    You will also note that after the retransmissions there are a couple of responses that come in very close together (less than 1ms apart).

    When data is retransmitted I believe (not my area so relying on this answer and assumptions!) that multiple packets may be combined. So I suspect you are seeing is:

    • Network connectivity issue starts
    • Client sends request
    • No response received so Client tries again (may happen multiple times)
    • Connectivity issue resolved
    • The packets sent while there was an issue are combined and retransmitted (handled by the network stack).