I am working for a company called HMS and we are manufacturing the device “Ewon Flexy”.
This device is an IOT gateway and it supports the MQTT protocol to send data to many different platforms (Mosquitto, Azure IOT HUb, Aws IOT,…). However I have been contacted by some of my customers because it does not work with Hive MQ for a reason we do not understand.
What we see from the device logs is that the TLS nego is ok and the device sends well a CONNECT packet with the options. Then HiveMQ responds back a CONNACK but then closes the connection.
I have tested the same settings/credentials with MQTT Fx and it works well.
I feel there is something in the CONNECT packet sent by the Ewon Flexy device that HIVE MQ does not like…
Could someone from Hive MQ support contact me back ? Could I have someone check the logs on your side (Instance 3495650d119e4ab4995be81a39545aac.s2.eu.hivemq.cloud) ?
Nice to meet IoT and MQTT enthusiast in our community, please welcome!
Does you device require a server CA in order to connect with TLS? If ‘yes’, you can download the root certificate here .
This will create a file called “isrgrootx1.pem”, which you can use as “Server Certiciate”.
Thx for this fast response.
Yes, it does and I have already set the certificat properly. As I said, it goes over the tls négociation and sends well the connect packet and receive a connack.
In case if you receive CONNACK then this is not a TLS problem.
You did not indicate yet, what version of MQTT your device supports: 3, 3.1.1, v5? But in case your device receives CONNACK with response code 5 (Not Authorised), this means that username or password your device sends inside the CONNECT packet is wrong or malformed.
You might want to intercept your CONNECT packet locally decode it and see what it actually sends inside the packed as username and password.
I hope this helps
Kind regards
Dasha from HiveMQ team
I have tested the version 3.1 and 3.1.1. The Flexy device does not support version 5.
“You might want to intercept your CONNECT packet locally decode it and see what it actually sends inside the packed as username and password.” I have no way to do from the device unfortunately. Could we arrange a live test so that you could check on your side ?
What is strange is that it works well with many different brokers… That makes me think it must be very specific to HiveMQ…
No, there is no alternative endpoint without encryption.
There is only another “public” broker broker.hivemq.com without encryption on port 1883. Testing and usage is for free but please do not use it for sensitive information because everybody is allowed to subscribe to every topic, including wildcard.
Can you take another look at your wireshark dump and check the TLS Client Hello?
For HiveMQ cloud we require the TLS-SNI extension to be available and used. (See screenshot below).
I had the same problem with my embedded MbedTLS client! Spent the entire day trying to figure out why I got a NOT AUTHORIZED error from the server until I found this post.
I think the HiveMQ team needs to fix this with a proper error code or fail a TLS handshake in the first place. Because it is incredibly confusing since the TLS handshake passes successfully, and the server processes CONNAC packet and then returns CONACK with an error code 5 (NOT AUTHORIZED), with actually has nothing to do with the problem itself!
