eclipse
Mosquitto_sub/pub sending messages with QoS 3
Version: 2.0.14 Platform: Windows 10
I am using mosquitto_sub and -_pub to test a mqtt-broker (FROST-Server) running on a local kubernetes cluster in Docker Desktop for Windows. To enable mqtt with tsl I opened port 8883 on the broker, for the start without any tls configurations and tested the connection with exactly the same arguments as for connections over port 1883, e.g.:
mosquitto_sub -h localhost -p 1883 -t test -d and
mosquitto_sub -h localhost -p 8883 -t test -d
Connections over port 1883 work perfectly, however connections over port 8883 fail with "Client null sending CONNECT" in loop.
The logs of the broker are reporting an error due to java.lang.IllegalArgumentException: invalid QoS: 3
I've double checked the broker with Node-Red as a second mqtt-client, which can establish connections over port 8883, ruling out the broker as the source of error.
Hey Ibung, did you figure it out?
If I recall correctly, to enable TLS on the mosquitto CLI clients, you need to do more than just switching to port 8883. You actually need to provide some SSL arguments, like for example, the CA root certificate. Otherwise it just does plain MQTT. Maybe this confuses the Frost Server somehow?
In my experience, the mosquitto_sub and pub clients tend to do a good job sanitizing the QoS, so it's always <= 2, so is weird to se a 3 there.
Hey abiliojr, not really.
the thing is, I do not want to enable TLS. I simply wanted to test the route to the mqtt-broker over port 8883, without TLS. The broker also has no TLS enabled, and other mqtt-clients (Node-RED) can communicate with it over port 8883 without TLS just fine.
After enabling TLS both on the broker and the mosquitto-client everything works as expected, so the issue only shows up while using the mosquitto-client over port 8883 without TLS.
The mosquitto clients assume that if you're using port 8883 you are using TLS. In 2.1 you will be able to disable this behaviour, but not in 2.0.x.
