[x] Bug exists Release Version 1.2.5 ( Master Branch)
[ ] Bug exists in MQTTv3 Client on Snapshot Version 1.2.6-SNAPSHOT (Develop Branch)
[ ] Bug exists in MQTTv5 Client on Snapshot Version 1.2.6-SNAPSHOT (Develop Branch)
Hi!
I am using Paho (Java) 1.2.5 as an MQTT client to communicate with Mosquitto 2.0.14 on Ubuntu 20.04.4. I am experiencing an issue when Paho has to re-publish a message due to the lack of an ACK from the broker after having been disconnected. More specifically, when I send a specific MQTT message with QoS 1/2 to the topic related to the DynSec plugin of Mosquitto, the broker disconnects the client without sending an ACK for the message (please refer to this issue for further information on why this happens).
The (potential) issue I would like to report does not involve the fact that Mosquitto disconnects the client without sending an ACK (obviously), but instead it is related to how Paho (Java) handles this situation. In detail, in my scenario:
Paho connects to Mosquitto with the cleanStart flag to false (to retain the session) and automaticReconnect to true;
Paho publishes a message to the DynSec topic with QoS 1/2, receiving a disconnect packet instead of an ACK (again, this is probably an issue/intended behaviour of Mosquitto, as discussed in the other issue);
Paho automatically reconnects to Mosquitto;
Paho tries to re-publish the message (since it did not receive the ACK). However, the message causes Mosquitto to reply with a disconnect packet with reason code 130 (i.e., protocol error).
At this point, it seems that either Paho (Java) or Mosquitto is doing something wrong. However, by investigating the packets flow with Wireshark, I noticed that the re-published message in step 4 by Paho does not include the topic name (i.e., the topic length is 0). Most probably, this is why Mosquitto replies with reason code 130.
I highlight that this problem does not happen with Paho (Python), as the re-published message contains the topic name (as shown in the other issue). Therefore, it seems to be an issue of Paho (Java).
You can find in this .zip file the configuration of Mosquitto and DynSec, the dump of Wireshark packets and a mock Kotlin code of the MQTT client to reproduce the behaviour. For your convenience, I report also below the log of the Mosquitto broker, the mosquitto.conf file content, the dynamic-security.json file content and the Kotlin code.
Thanks in advance!
Stefano
The Mosquitto broker log:
- 1647012876: mosquitto version 2.0.14 starting
- 1647012876: Config loaded from /mosquitto/config/mosquitto2.conf.
- 1647012876: Loading plugin: ./usr/lib/mosquitto_dynamic_security.so
- 1647012876: Opening ipv4 listen socket on port 1883.
- 1647012876: Opening ipv6 listen socket on port 1883.
- 1647012876: mosquitto version 2.0.14 running
- 1647012887: New connection from 10.1.0.1:56788 on port 1883.
- 1647012887: New client connected from 10.1.0.1:56788 as randomClientID (p5, c0, k120, u'admin').
- 1647012887: No will message specified.
- 1647012887: Sending CONNACK to randomClientID (0, 0)
- 1647012888: Received PUBLISH from randomClientID (d0, q1, r0, m1, '$CONTROL/dynamic-security/v1', ... (178 bytes))
- 1647012888: dynsec: randomClientID/admin | createRole | rolename=roleName1
- 1647012888: Sending PUBACK to randomClientID (m1, rc0)
- 1647012889: Received PUBLISH from randomClientID (d0, q1, r0, m2, '$CONTROL/dynamic-security/v1', ... (222 bytes))
- 1647012889: Client randomClientID been disconnected by administrative action.
- 1647012889: dynsec: (null)/admin | addClientRole | username=admin | rolename=roleName1 | priority=-1
- 1647012889: Sending PUBACK to null (m2, rc0)
- 1647012889: Client <unknown> disconnected due to out of memory.
- 1647012890: New connection from 10.1.0.1:56790 on port 1883.
- 1647012891: New client connected from 10.1.0.1:56790 as randomClientID (p5, c0, k120, u'admin').
- 1647012891: No will message specified.
- 1647012891: Sending CONNACK to randomClientID (0, 0)
- 1647012891: Client randomClientID disconnected due to protocol error.
Hi! I am using Paho (Java) 1.2.5 as an MQTT client to communicate with Mosquitto 2.0.14 on Ubuntu 20.04.4. I am experiencing an issue when Paho has to re-publish a message due to the lack of an ACK from the broker after having been disconnected. More specifically, when I send a specific MQTT message with QoS 1/2 to the topic related to the DynSec plugin of Mosquitto, the broker disconnects the client without sending an ACK for the message (please refer to this issue for further information on why this happens).
The (potential) issue I would like to report does not involve the fact that Mosquitto disconnects the client without sending an ACK (obviously), but instead it is related to how Paho (Java) handles this situation. In detail, in my scenario:
cleanStart
flag tofalse
(to retain the session) andautomaticReconnect
totrue
;At this point, it seems that either Paho (Java) or Mosquitto is doing something wrong. However, by investigating the packets flow with Wireshark, I noticed that the re-published message in step 4 by Paho does not include the topic name (i.e., the topic length is 0). Most probably, this is why Mosquitto replies with reason code 130.
I highlight that this problem does not happen with Paho (Python), as the re-published message contains the topic name (as shown in the other issue). Therefore, it seems to be an issue of Paho (Java).
You can find in this .zip file the configuration of Mosquitto and DynSec, the dump of Wireshark packets and a mock Kotlin code of the MQTT client to reproduce the behaviour. For your convenience, I report also below the log of the Mosquitto broker, the mosquitto.conf file content, the dynamic-security.json file content and the Kotlin code.
Thanks in advance! Stefano
The Mosquitto broker log:
The mosquitto.conf file content:
The dynamic-security.json file content:
The Java code: