Messages with NUL character get truncated

[Wolfgang Nagele]

When sending in a message that contains \0 (NUL) anywhere in the payload it seems that the message is truncated at that very position and the rest of the payload is not delivered.

Here is an example:

We are sending in the message "test\0\0\0".
$ hexdump in
0000000 74 65 73 74 00 00 00
0000007

As expected the message has the four ASCII characters followed by three NUL control characters.

The message received is only "test".
$ hexdump out
0000000 74 65 73 74 0a
0000005

Ignore the 0a here as this is the newline that was added by mosquitto_sub which is fine.

[Roger Light (roger.light)]

Could you clarify how you are sending the message, i.e. what client?

[Wolfgang Nagele (mail-wnagele)]

Looks like the bug is in mosquitto_sub. It works fine if I use the Python module or Eclipse Paho to read the payload. I currently publish using Eclipse Paho and mosquitto_pub.

[Wolfgang Nagele (mail-wnagele)]

Had some time to look into the code around this and it's no surprise. mosquitto_sub expects strings in the payload only as it prints them out using printf (https://bitbucket.org/oojah/mosquitto/src/9312f0265f45fb5f7a2cb5d92d7b70e921053a98/client/sub_client.c#cl-70). This is also why control characters such as \0 cause issues.

Not sure if this is something that should/could be fixed or if mosquitto_sub simply should not be used for binary payloads?

[Wolfgang Nagele (mail-wnagele)]

Attached is a patch that uses fwrite to support binary payloads.