LWT Will message is not complete

[HankB]

Testing with sample code async_publish.cpp and inserting abort() at line 195 to cause the program to abort w/out cleaning up the connection (and thus causing the broker to publish the will message.) Only the first character of the will message is published. Example output from another client listening to the same broker is

hbarta@olive:~$ mosquitto_sub -v -t \#
hello Hello World!
hello Hi there!
hello Is anyone listening?
hello Someone is always listening.
hello L

Output form the program itself is

hbarta@olive:~/Programming/C++$ ./async_publish
Initializing for server 'tcp://localhost:1883'...
  ...OK

Connecting...
Waiting for the connection...
  ...OK

Sending message...
	Delivery complete for token: 1
  ...OK

Sending next message...
  ...with token: 2
  ...for message with 9 bytes
	Delivery complete for token: 2
  ...OK

Sending next message...
	Listener success for token: 0
  ...OK

Sending final message...
	Listener success for token: 0
OK
Aborted
hbarta@olive:~/Programming/C++$ 

And command to build the program is

g++ -o async_publish -Wall async_publish.cpp -lpaho-mqttpp3 -lpaho-mqtt3as -lpthread

I have tested the C library similarly (inserting abort() at line 509 in paho_c_pub.c) and verified that the entire will message is printed.

[fpagliughi]

That's odd... The LWT message goes to the broker inside the initial connect message. After that the client has nothing to do with its delivery. Can you spy on the packets with Wireshark or something to see if the connect message seems properly formed? (i.e. has the whole LWT payload?)

And, it would be pretty odd for the connection to be accepted if the connect message was malformed.

[HankB]

Here is a copy of the information presented by Wireshark.

MQ Telemetry Transport Protocol, Connect Command
    Header Flags: 0x10, Message Type: Connect Command
    Msg Len: 44
    Protocol Name Length: 4
    Protocol Name: MQTT
    Version: MQTT v3.1.1 (4)
    Connect Flags: 0x06, QoS Level: At most once delivery (Fire and Forget), Will Flag, Clean Session Flag
    Keep Alive: 60
    Client ID Length: 22
    Client ID: paho_cpp_async_publish
    Will Topic Length: 5
    Will Topic: hello
    Will Message Length: 1
    Will Message: 4c

0000   00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010   00 62 23 33 40 00 40 06 19 61 7f 00 00 01 7f 00   .b#3@.@..a......
0020   00 01 8a 34 07 5b a4 67 e7 69 e5 f6 4f 3f 80 18   ...4.[.g.i..O?..
0030   02 00 fe 56 00 00 01 01 08 0a 10 32 ee 2e 10 32   ...V.......2...2
0040   ed cb 10 2c 00 04 4d 51 54 54 04 06 00 3c 00 16   ...,..MQTT...<..
0050   70 61 68 6f 5f 63 70 70 5f 61 73 79 6e 63 5f 70   paho_cpp_async_p
0060   75 62 6c 69 73 68 00 05 68 65 6c 6c 6f 00 01 4c   ublish..hello..L

If there is further information in the Wireshark capture, you will need to guide me as to how to present it as I am not that conversant with Wireshark. I don't see any indication in the entire transaction or the Mosquitto broker log indicating that there is anything malformed in the communication. (And except for the inserted abort() call, this is one of the example programs that come with the C++ library.)

Edit: I have been negligent in not mentioning that I am building against the The C++ package built from the repo and linked against Debian (Bullseye) package libpaho-mqtt1.3.

Thanks!

[fpagliughi]

No that's shows what I was wondering about:

Will Message Length: 1
Will Message: 4c

So, the client (app or library) is giving the broker a LWT message with a payload that has only one character.
And then the server is properly sending out that single-char LWT when the client app drops the connection.

Can you post a code snippet for the client? Is it literally the example app with an abort() thrown in?

[HankB]

It is literally the sample app with the abort() thrown in. It was the easiest way I could see to provoke the broker to send the will message.
I first experienced this with an app I'm working on. I modified the sample app to determine whether it was something I was doing wrong or something in the C++ library. I can't rule out that the C++ sample is also doing something wrong.

[YeahhhhLi]

// message.h
message(string_ref topic, const void* payload, size_t len)
		: message(std::move(topic), payload, len, DFLT_QOS, DFLT_RETAINED) {}
message(string_ref topic, const void* payload, size_t len,
			int qos, bool retained,
			const properties& props=properties())；

// async_publish.cpp
const char* LWT_PAYLOAD = "Last will and testament.";
const int  QOS = 1;

auto connOpts = mqtt::connect_options_builder()
		.clean_session()
		.will(mqtt::message(TOPIC, LWT_PAYLOAD, QOS))
		.finalize();

It seems that there is a problem with the sample writing.
The will message is complete when I modify it as follows:

auto connOpts = mqtt::connect_options_builder()
		.clean_session()
		.will(mqtt::message(TOPIC, LWT_PAYLOAD, strlen(LWT_PAYLOAD), QOS, /*retained*/true))
		.finalize();

[fpagliughi]

🤦

Only took a year... Now I see it. Yeah, I used QoS for the LWT message length parameter!

Thanks for the help. I'll get the fix in now...

[fpagliughi]

Fixed in v1.3.2