Ask Your Question

Wireshark incorrectly interpreting the format of MQTT PUBLISH payload data

asked 2019-04-30 08:14:47 +0000

updated 2019-04-30 08:15:01 +0000

I'm not sure if this is a good place to post this, please let me know if it's not and I'll post it where it's appropriate.

The current version (v3.0.1-0-gea351cd8) of WireShark seems to interpret MQTT publish messages as null-terminated strings, and consumes them in the process. Here is an example of a PUBLISH containing bytes 31 02 33 0 31 02 33 as an example:


As you can see, the current MQTT dissector treats the message as a null-terminated string, parsing 31 02 33 as an ASCII string and inserting \0xx in place of control characters, then stops at the zero byte, and doesn't parse the remaining payload bytes.

The MQTT 3.1.1 standard states, that:

The Payload contains the Application Message that is being published. The content and format of the data is application specific. The length of the payload can be calculated by subtracting the length of the variable header from the Remaining Length field that is in the Fixed Header. It is valid for a PUBLISH Packet to contain a zero length payload.

Since the payload format is application specific, I think that the correct behavior would be similar to for example TCP - to not consume the payload at all and instead leave it as "Data", allowing for other application specific dissectors to consume and parse the data. I'm not sure what's the correct term for this, but I was able to reproduce this behavior by going to Edit > Preferences > Protocol > MQTT > Edit, and manually adding an entry to not decode payloads on any topics.

Manual configuration

Semi-correctly parsed data

This makes the dissector correctly pass on the payload as "Data", but the warning message still remains. This should be the default behavior without configuring, and the warning message should probably be removed. Here's a capture file with an example of the publish packet.

Is there any chance of getting this fixed?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2019-04-30 08:29:53 +0000

grahamb gravatar image

All bugs, issues and enhancements should be reported at the Wireshark Bugzilla, first checking for an existing item for the bug\issue\enhancement, and if none found raise a new one. Attaching a capture to the item helps immensely.

edit flag offensive delete link more


Thank you, I opened a bug report, I'll leave a link here's if someone stumbles across this later on: Bugzilla item 15738

GediminasMasaitis gravatar imageGediminasMasaitis ( 2019-04-30 10:16:31 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2019-04-30 08:14:47 +0000

Seen: 1,298 times

Last updated: Apr 30 '19