This is our old Q&A Site. Please post any new questions and answers at

When monitoring Modbus TCP, Wireshark seems to attempt to break down the data. It incorrectly interprets an ieee float as two UINT16 values. What configuration controls how the datagram is dissected? Likewise when monitoring encapsulated or wrapped Modbus Rtu, the datagram shows the raw data. I have not figured out how to apply the correct data intrepretation within TCP.


asked 26 Nov '13, 14:28

btanner's gravatar image

accept rate: 0%

Looks like the Lua scripting language is what I was looking for for creating easy dissectors.

(12 Dec '13, 08:53) btanner

You could also look at WSGD that generates a dissector from a text file. Modbus traffic should be OK to handle with WSGD.

(13 Dec '13, 01:41) grahamb ♦

What configuration controls how the datagram is dissected?

The source code that's compiled into Wireshark; we currently don't have anything such as the Wireshark Generic Dissector built into Wireshark and thus aren't using anything such as that to describe protocols in a fashion that would let users fix protocol dissection by editing a text file and restarting Wireshark. Instead, bugs in dissection need to be fixed by changing the source code for the dissector and recompiling.

Please file a bug on this on the Wireshark Bugzilla, and please attach capture files (not screenshots, actually capture files) that demonstrate this problem.

permanent link

answered 26 Nov '13, 14:34

Guy%20Harris's gravatar image

Guy Harris ♦♦
accept rate: 19%

What version of Wireshark?

This is not a bug. The Modbus protocol has no indication that two registers are to be treated as a 32 bit float, that is known only at the originating and receiving ends. This is a limitation in the Modbus protocol that is built around the simple data types of a single bit digital (coil) and a 16 bit register. Modbus isn't known as the lowest common denominator of the telemetry world for nothing.

However, some preferences and logic have been put into the Modbus data dissector such that if the function is either; Read Holding Registers (03), Read Input Registers (04) or Write Multiple Registers (16) and the number of data bytes is a multiple of 4, and the dissector preferences have been set to interpret data as a 32 bit value (32 bit uint, 32 bit IEEE float, 32 bit Modicon float), then the data will be dissected as such.

Note that there are separate data format dissector preferences for Modbus TCP and Modbus RTU.

Note that the preferences and logic are all or nothing, so that you can't have one of the function codes above, with the number of data bytes a multiple of 4 and the data containing a mix of 16 bit and 32 bit values interpreted correctly.

There have also been other additions to Wireshark so that if Modbus RTU (which is normally used over a serial line) is transmitted over a network (usually via a terminal server to the RTU), then the Modbus dissector will attempt to decode that data as well. In this case you must set the Modbus RTU Port value in the Modbus RTU dissector preferences, as there is no standard port for this, unlike Modbus TCP (502).

What do you mean by "encapsulated or wrapped Modbus RTU"?

I tested both these aspects today with Wireshark 1.10.3 64 bit.

permanent link

answered 26 Nov '13, 23:00

grahamb's gravatar image

grahamb ♦
accept rate: 22%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 26 Nov '13, 14:28

question was seen: 5,001 times

last updated: 13 Dec '13, 01:41

p​o​w​e​r​e​d by O​S​Q​A