In working on migrating a project to the newer Anycloud MQTT Client project, I noticed that when I published messages to the client, the MQTT broker w...
Show More
In working on migrating a project to the newer Anycloud MQTT Client project, I noticed that when I published messages to the client, the MQTT broker would close the TCP/IP socket, thus disconnecting from the client. This is caused by the client not sending a PINGREQ in the allotted MQTT_KEEP_ALIVE_SECONDS time and the MQTT broker assumes the client no longer exists.
I would expect the client to stay connected regardless of Quality of Service, but the broker disconnects occur with QoS of 0. I have yet to see a disconnect when publishing to the client with a QoS of 1.
While this issues exists with version 4.0.0 of the demo project and with the ModusToolbox v2.4.0 toolset, it is reproducible with the latest version of the demo project and version 3.0.0 of ModusToolbox.
To duplicate the issue:
- Create the project as in the Readme.md: project-creator-cli --board-id CY8CKIT-062S2-43012 --app-id mtb-example-wifi-mqtt-client --user-app-name MQTTClient --target-dir .
- Modify config/wifi_config.h to local router
- Modify config/mqtt_client_config.h to local Mosquitto broker (ensures only local traffic) and MQTT_KEEP_ALIVE_SECONDS to 5 (reveals issue faster).
- make build -j8; make program
- Publish to client: mosquitto_pub -h 192.168.4.2 -t "ledstatus" -m "0123456" -q 0
There isn't a disconnect every time publishing to the client with QoS of 0, but I've attached client output, the mosquitto broker log, and a Wireshark capture of where the first publish to the client causes the client to stop making PINGREQs.
In this instance, the broker is 192.168.4.2 and the client is 192.168.4.10. In the Wireshark capture, the last PINGREQ is highlighted, packet 26. In packet 30, the broker closes the socket about 7.2 seconds after the last request which is almost 1.5x the keep alive timeout. The second Wireshark screenshot shows packet 28 with the PUBLISH packet and that it's a QoS of 0 or "Fire and Forget".
The default Quality of Service is set to 1 and when I publish to the client with a QoS of 1, I do not see the disconnect. I also set the changed MQTT_MESSAGES_QOS to 0 for the client, but I still saw the broker disconnect when publishing to the client with QoS of 0.
I noticed a similar problem with version 4 of the demo and v2.4 of ModusToolbox when I add a hardware timer. For some reason, the FreeRTOS software timer used generate the PINGREQ failed to fire and the MQTT broker would disconnect due to a timeout.
Thankfully, it seems that I can work around this issue by changing all of my publishes to a QoS of 1, but it would be nice to use a QoS based on the design and not a work around.
Any help would be appreciated,
Matt
Show Less
Solved
