@chaiyasitr am using Quectel bg95 modem.
Yes I can connect to test.mosquitto.org:8885 and can confirm I can publish and read messages with the different users.
@nofan Thank you for quick reply.
Yes, maybe we are facing the same problem.
Regards,
@chaiyasitr can you use wireshark and grab the MQTT Connect command packet and sharing it with me.
just connect to test.mosquitto.org:1884 : MQTT, unencrypted, authenticated and copy the hex dump.
you can use dummy deviceID and credentials.
you can also save and share the tcp stream and send it to Hivemq and they can recreate the packets to their TLS server
MQTT.FX connection worked my bad. wrong cluster address.
meanwhile, I will investigate more into this issue
@Daria_H can you please provide a test server with weak SSL so you can view incoming packets. the only thing that I noticed is that mosquitto servers use MQTT PACKET with a TCP wrapper. you guys use pure MQTT protocol which might be the difference in embedded systems.
@nofan Give me a time, I will try to use wireshark.
regards,
@chaiyasitr @Daria_H Hello again I have captured the data from my local Hivemq.
I didn’t configure it to user SSL yet just to prove that the encoding is fine.
I will look at auth method =0 and test it further.
If someone from support can help us to trace SSL connection on a cluster this will save me so much time.
Trace
2022-03-31 12:58:37,027 - [bg95Test] - Received CONNECT message (mqtt version: MQTTv3_1, client identifier: bg95Test, clean start: true, keep alive: 120, session expiry interval: 0, topic alias maximum: 0, receive maximum: 65535, maximum packet size: 268435460, request response information: false, request problem information: true, auth method: none, username: bg95Test, password: bg95Test1)
2022-03-31 12:58:37,090 - [bg95Test] - Sent CONNACK message (session present: false, retain available: true, shared subscriptions available: true, subscription identifier available: true, wildcard subscriptions available: true, maximum packet size: 268435460, server receive maximum: 65535, topic alias maximum: 0, reason code: 0)
and this is the hex dump from wireshark
00000000 10 2b 00 06 4d 51 49 73 64 70 03 c2 00 78 00 08 .+…MQIs dp…x…
00000010 62 67 39 35 54 65 73 74 00 08 62 67 39 35 54 65 bg95Test …bg95Te
00000020 73 74 00 09 62 67 39 35 54 65 73 74 31 st…bg95 Test1
00000000 20 02 00 00 …
Dear HiveMQ support,
Please test the above MQTT CONNECT packet with your callbacks to see why my device and @chaiyasitr 's can not connect to our clusters with NOT_AUTHORIZED return in our clusters mentioned above.
@nofan Many thanks.
Let me know if you need my support.
I will try to use wireshark on test.mosquitto.org:1884 : MQTT, unencrypted, authenticated.
@Daria_H @DKrueger kindly help @nofan.
regards,
So the traced connect packet looks fine. I added the bytes into a unit test for the connect decoder and the result looks fine.
username: bg95Test
password (interpreted as UTF8): bg95Test1
Just like shown in the trace log.
I do not understand why it does not work with tls. Is the password for the cloud also alpha-nummeric? If not, can you do another test (capturing the connect bytes) with a password that is not alpha-nummeric (or rather not ACII compatible). I really think this could be the problem.
Usually TLS implementations work or they fail on the handshake sequence. Also I believe the can decode the CONNECT successfully, we would not send NOT_AUTHROIZED otherwise, but close the tcp connection.
Best regards, Daniel
So this line can not work with UTF8 characters outside of the ASCII compatible section:
char * password = MQTT_PASSWORD;
Background char was designed as a 1byte data type. However this is problematic with encodings that need a more space. Therefor UTF8 and other encodings were created. These encodings use more byte (if the symbol to be encoded is outside the extended ASCII).
This source line will likely reduce any not ASCII compatible char to the 8 less-significant bits - I assume. or it will interpret it as more ASCII characters. The encoded connect will still be correct, but the byte array that represents the password will not be the password you set and as a result authorization will fail.
There are other data types in C for UTF8-compatible strings:
To test my assumption, change/create a user in hivemq clould whose password and username only includes lower and upper case letters and numbers.
My username is TestDevice001 and password is Pass123456789, that it doesn’t work.
Regrds,
We need someone who has a tls enabled server or someone from support to start a trace and capture the username/password from the server.
The first 127 chars in UTF8 are ascii char bytes with only 1 byte. Maybe Hivemq auth call backs treat UTF8 chars as 3 bytes.
Ex ‘1’ is 0x31 in ascii and 0x00 0x00 0x31 in utf8.
Regards
my cluster address is
4b9fa9f2ad4c424fa69f8642878e39c4.s2.eu.hivemq.cloud port 8883
username: bg95Test
password: bg95Test1
you can connect and confirm credentials.
here is another test I have done using MQTT 3.1.1
0000 68 b5 99 c9 25 dc 6c 50 4d d7 9f 93 08 00 45 00 h…%.lPM…E.
0010 00 53 00 5e 00 00 f4 06 e7 46 25 27 f7 5e c0 a8 .S.^…F%’.^…
0020 01 d2 3a 85 07 5b 88 eb 80 01 d7 38 14 d7 50 18 …:…[…8…P.
0030 40 00 47 77 00 00 10 29 00 04 4d 51 54 54 04 c2 @.Gw…)…MQTT…
0040 00 3c 00 08 62 67 39 35 54 65 73 74 00 08 62 67 .<…bg95Test…bg
0050 39 35 54 65 73 74 00 09 62 67 39 35 54 65 73 74 95Test…bg95Test
0060 31 1
and compared it with the Hex Dump from a connection from MQTT.FX
0000 68 b5 99 c9 25 dc 6c 50 4d d7 9f 93 08 00 45 00 h…%.lPM…E.
0010 00 53 77 7b 40 00 78 06 b1 55 25 22 f2 37 c0 a8 .Sw{@.x…U%".7…
0020 01 d2 c5 ed 07 5b 07 29 fc a2 29 15 fa 52 50 18 …[.)…)…RP.
0030 01 02 ce 01 00 00 10 29 00 04 4d 51 54 54 04 c2 …)…MQTT…
0040 00 3c 00 08 62 67 39 35 54 65 73 74 00 08 62 67 .<…bg95Test…bg
0050 39 35 54 65 73 74 00 09 62 67 39 35 54 65 73 74 95Test…bg95Test
0060 31 1
it must be something with the callbacks not encoding unless TLS MQTT connect packet is different.
So if you can please provide a tls enables server where you can trace the packet and make sure it’s fine.
Regards
P.S packets are captured from server side not from the client side.
@nofan ‘1’ should be 0x31 in both ASCII and in UTF8. (see: UTF-8 code page). It does not make sense to add empty bytes. ASCII chars will be encoded the same way, thats a main point on utf-8.
The usage of TLS is intransparent for the broker, besides the socket implementation. However as different listeners are used, the listeners might be configured different. I try to get information on that.
Best Regards, Daniel
Hello,
Can you take another look at your wireshark dump and check the TLS Client Hello?
For Free and Pay As You Go, we require the TLS-SNI extension to be available and used. (See screenshot below).
We ran some tests on embedded C clients so far, but only on the Arduino platforms. Those do support TLS-SNI.
I have enabled SNI but nothing changed
+QSSLCFG=“sni”,2,1
OK
+QMTOPEN=0,“4b9fa9f2ad4c424fa69f8642878e39c4.s2.eu.hivemq.cloud”,8883
OK
+QMTOPEN: 0,0
+QMTCONN=0,“test_topic”,“bg95Test”,“bg95Test1”
OK
+QMTCONN: 0,0,5 <--------- return code 5 NOT_AUTHORIZED
+QMTSTAT: 0,4
@simon_b yes I haved used Arduino to connect with HiveMQ with no problems.
but with advanced systems we can not use arduino
@DKrueger Did you have a chance to have a look at the listeners ?