Tshark doesn’t display mbtcp function 4 modbus.data

Question

Hi,

I'm completely new to tshark so any help would be much appreviated also quite new to Modbus.

I'm trying extract the raw modbus data from a capture. I've used similar code found in another question Tshark doesn't display the longer data fields (mbtcp) but I believe this is a different issue as I'm using standard function codes.

I have filtered the wireshark data for ip.addr and mbtcp then passed the result through

tshark -o "opensafety.enable_mbtcp:0" -nr capture.pcapng -Y "mbtcp" -T fields -E header=y -e ip.src -e ip.dst -e mbtcp.unit_id -e modbus.func_code -e modbus.data > tshark_out.txt

modbus.data only extracts with function code 2 not 4. I have tried the suggestion on the link and included '-o "opensafety.enable_mbtcp:0"' but that doesn't look to sort my issue. Is there anything further someone could suggest that i'm missing?

Output example:
ip.src ip.dst mbtcp.unit_id modbus.func_code modbus.data
192.168.0.10 192.168.0.20 10 4
192.168.0.20 192.168.0.10 10 4
192.168.0.10 192.168.0.20 10 2
192.168.0.20 192.168.0.10 10 2 00:00:00

Also I would like to pull out the query start address and less importantly the number of registers to read but I can't find a -e field that will do this. Is it possible?

Any insight would be greatly recieved as I've been trying to figure this out for a while now. Thanks, Alex

Answer 1

Function code 4 is "read input registers", where the request payload (the first frame in your text output) consists of the starting register offset (16 bits) and the count of registers to read (also 16 bit). These two files have field identifiers of modbus.reference_num and modbus.word_cnt respectively.

The response (the 2nd frame in your text) will have an 8 bit byte count (field identifier modbus.byte_cnt) followed by the register data. The register data is decoded according to the dissector preference "Holding/Input Register Format", which defaults to unsigned 16 bit integers, the field identifier for this data is modbus.register.uint16. I'm not certain how multiple registers will be displayed with a single -e modbus.register.uint16 argument, I'll test later at work.

The modbus.data field identifier is only used to output "raw" values where there is an issue with the data (incorrect length) or a 32 bit format is specified in the preferences but there aren't 4 bytes of data, or an unknown function code.

You can easily determine field identifiers yourself by clicking on a field in the packet details tree and checking the status bar where the field identifier is shown in parentheses.

If you can share a capture with the required data (in a public spot, e.g. Cloudshark, Google Drive etc.), then that will help to analyse your issue.