Packet size limited during capture: Modbus RTU truncated

[JamesBewley]

I just started using this to sniff an RS-485 network but I don't appear to be able to view the longer packets. The packet get split across several rows in wireshark with "Unable to classify as query or response" against each subsequent row.

Is this a problem with the capture? settings in wireshark?

Any help much appreciated.

Here is an example with 70 bytes response.

Poll: 01 03 00 F3 00 38 B4 2B
Response: 01 03 70 00 00 11 E1 00 00 00 00 00 00 EA 89 00 03 00 00 00 00 E6 03 00 03 00 00 00 00 E2 6D 00 07 00 00 00 00 F7 62 00 03 00 00 00 00 F0 44 00 03 00 00 00 00 EB 3F 00 03 00 00 00 00 D2 E5 00 0B 00 00 00 00 FB AA FF FF FF FF FF FF FA 46 FF FF FF FF FF FF FA C4 FF FF FF FF FF FF F0 B4 FF FF FF FF FF FF A5 81 FF FF FF FF FF FF A7 F6 FF FF FF FF 50 E5

[j123b567]

This tool splits packets just by inter frame gap. It does not try to understand the protocol itself. There are several possibilities for you

1. you really have large gaps in the response so it is treated as separate frames. Please verify this by logic analyzer, osciloscope or so.
2. you are using wrong/misconfigured hardware so it inserts artifical gaps. I'm using this tool on Linux with FTDI based USB/UART converter and "Latency timer" set to lowest possible value. There is similar setting for Windows.
3. if you don't care about inter frame gaps, you can reorganize packets so they will be valid, but you loose information about exact timing. Here is an example how to do it https://gist.github.com/j123b567/37153ba4d3a365cdfbce076e38ffd14d

Just some notes:

Inter frame gap is the only correct way how to packetize Modbus/RTU on RS-485. You should never try to understand partial packet before you recognize inter frame gap. You should also never try to response or ask another request in shorter time then inter frame gap.

I used this tool to discover timing issues on my implementation of Modbus/RTU so it is crucial feature for me to split incorrectly timed packets in to several lines for Wireshark. Simply, because all other devices on the same bus will see also multiple packets and not the long one if they are implemented correctly according to previous note.

[JamesBewley]

Excellent response.

I'm pretty sure there is nothing corrupting the messages since the data looks ok and in the correct order so guess my prolific USB serial adapter must be chopping them up. I don't appear to have a "low latancy" option so will try reassembling the MODBUS frames using your tool.

Thank you very much.