Incompatability with MQTT 2.0.14

[jayrock 10]

I upgraded my broker from 2.0.3 to 2.0.14 an keep getting error code 2 on connect:

 

Code:

 

Please login or register to see this code.

Log:

Please login or register to see this code.

 

Downgrading to 2.0.3 removes the error.

 

According to the 

Please login or register to see this link.

, error code 2 means "The Client identifier is correct UTF-8 but not allowed by the Server". The

Please login or register to see this link.

say clientId – (of type string) an identifier of each MQTT client connecting to an MQTT broker. If no ID is given, a random ID will be generated; so I'm not sure what the problem is.

 

FWIW I have some python clients that work fine with any MQTT broker version.

 

I'd be glad about any suggestions!

 

Thanks,

jayrock

[petergebruers 1,268]

I am not at home so I cannot test but I am pretty sure I am running 2.0.11

 

Did you check if this is (still) in /etc/mosquitto/mosquitto.conf

 

listener 1883
allow_anonymous true

 

That's something that bit me when I went from 1.X to 2.X - so not sure how relevant it is in case you upgrade from 2.X to 2.7, but you said I'd be glad about any suggestions! so here you have one

[jayrock 10]

Thanks for the quick return.

 

allow_anonymous true is there, I also remember it was needed when I first move to 2.x

 

listener 1883 is actually commented out, but it is the default port and I can see that my other clients use it. I also checked with mqtt-spy.

 

So, IMHO, all points to the client on HC3.

 

 

[petergebruers 1,268]

37 minutes ago, jayrock said:

So, IMHO, all points to the client on HC3

I would say yes, based on your observations. I might give 2.0.14 a try next week. Just to confirm the situation. I am lazy as it comes to updating the broker ( you know: apt update and upgrade and accept what they offer) Maybe I should update more often for security reasons?

[jayrock 10]

Same here, I just updated today for fun... quite a step from .3 to .14

 

Would be great if you could confirm the issue (or not).

 

/jayrock

[petergebruers 1,268]

I had 30 minutes so here we go. I cannot confirm the issue but I also cannot fully dismiss it... For several reasons but the most important on is that "debian bullseye" hasn't updated to .14 yet (Package search says: mosquitto (2.0.11-1)). So I had to build mosquitto "from source" and I don't know if debian tweaks some of its settings. Here we go!

 

./mosquitto -v
1645297752: mosquitto version 2.0.14 starting

 

Then I point it at my config file and let it run.

 

1645297507: New connection from 192.168.0.51:35358 on port 1883.
1645297507: New client connected from 192.168.0.51:35358 as HC3 (p2, c0, k20).
 

The identifier "HC3" is what I've assigned in my FQA.

 

Then on the HC3 I run my test(s)

 

[19.02.2022] [20:05:07] [DEBUG] [QUICKAPP1762]: connected: {"returnCode":0,"sessionPresent":true}
[19.02.2022] [20:05:07] [DEBUG] [QUICKAPP1762]: subscribed: {"results":{"0":0},"packetId":1}
[19.02.2022] [20:05:17] [DEBUG] [QUICKAPP1762]: published: {"packetId":2}
[19.02.2022] [20:07:15] [DEBUG] [QUICKAPP1762]: message: {"payload":"","retain":false,"dup":false,"qos":0,"topic":"test\/hello"}

Seems OK.

 

This is the main body of my quickapp, maybe the secret is hidden in there? I don't know...

 

Please login or register to see this code.

 

Edited February 19, 2022 by petergebruers

[petergebruers 1,268]

Oh, errrm, maybe the most obvious difference between both FQAs is this... I call 

 

mqtt.Client.connect

 

With several parameters, first one being the ID:

 

Please login or register to see this code.

 

[jayrock 10]

OK, let me try... I have multiple QAs subscribing to different topics.

[petergebruers 1,268]

A thing struck my mind, I read about "client id" on several occasions and quite a few softwares seems to generate a random ID which seems counter-intuitive to me because its purpose is to let client and broker now "we are the same" - so connections can be dropped en reestablished... This documentation is not canonical but IMHO they are doing a good job at making the MQTT protocol understandable

 

Please login or register to see this link.

 

A quote

 

ClientId
The client identifier (ClientId) identifies each MQTT client that connects to an MQTT broker. The broker uses the ClientId to identify the client and the current state of the client.Therefore, this Id should be unique per client and broker. In MQTT 3.1.1 you can send an empty ClientId, if you don’t need a state to be held by the broker. The empty ClientId results in a connection without any state. In this case, the clean session flag must be set to true or the broker will reject the connection.

Clean Session
The clean session flag tells the broker whether the client wants to establish a persistent session or not. In a persistent session (CleanSession = false), the broker stores all subscriptions for the client and all missed messages for the client that subscribed with a Quality of Service (QoS) level 1 or 2. If the session is not persistent (CleanSession = true), the broker does not store anything for the client and purges all information from any previous persistent session.

 

I am not 100% sure but I have a gut feeling, based on that quote, I would say "empty name ClientId is good if you set clean session and do not want state". On the other hand, a fixed ClientId for your QA seems good as well. My least favorite would be a random ID and Fibaro says "If no ID is given, a random ID will be generated". I am not sure if you can do clientId=""  - to send empty ClientId.

 

Still doesn't fully explain why you had issues on 2.0.14 and not before... Maybe the broker got more strict about certain settings?

Edited February 21, 2022 by petergebruers

[jayrock 10]

Thanks for digging that out, I must have missed it. I think we converge on the description of the problem  

 

I was thinking about adding the QA id as the client id anyway; or, set the clean session flag based on the quote. I need to rework the QA template and deploy it to 15 QAs - will need some time and concentrate.

 

After that, I will report back.

 

Cheers,

 

jayrock

[jayrock 10]

Here are some more findings:

 

- Your code works well on HC3 with MQTT 2.0.14

- Your code works well with HC3 emulator

 

- My code crashes on HC3 with MQTT 2.0.14

- My code runs fine with HC3 emulator after I manually added the port.  

Please login or register to see this code.

 

The first thing I tried is to have the compete set of parameters taken from your connect line

Please login or register to see this code.

 

Again, same error.

 

 

@petergebruers I see that you have a pcall wrapper around Client.connect, otherwise I don't see much difference. I'm tempted to steal your code fully and stop bothering where the error is. If someone feels challenged, below is my complete code

 

Cheers,

jayrock

 

Please login or register to see this code.

 

Edited February 21, 2022 by jayrock

[jayrock 10]

So, I found another syntax error in handleClosed and handleError, and I copied @petergebruers connect. Now it works with MQTT 2.0.14. I don't know why exactly, but it doesn't matter.

 

For those who are interested, here is the updated code:

 

Please login or register to see this code.