GediminasMasaitis's profile - activity

Thank you, I opened a bug report, I'll leave a link here's if someone stumbles across this later on: https://bugs.wiresh

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.

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?

Thank, you I opened a bug report, I'll leave a link here's if someone stumbles across this later on: https://bugs.wiresh

Wireshark incorrectly interpreting the format of PUBLISH payload data I'm not sure if this is a good place to post this,

Wireshark incorrectly interpreting the format of PUBLISH payload data I'm not sure if this is a good place to post this,