Publishing QoS=0 Messages to Anycloud MQTT Client Causes Broker Disconnect

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
MattTreiber
Level 3
Level 3
25 sign-ins 10 replies posted 10 sign-ins

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

1 Solution

I have been able to find a fix in ensuring that when publishing to the client the QoS should match what the client is expecting. In our case, we control both ends of the design so this is not an issue for us. 

I did program the client to expect QoS of 2, but when publishing to the client with a QoS of 0 or 1 when it expects 2, it will still occasionally disconnect.

So when there is a mismatch, the FreeRTOS timer used to send the PING_REQ does not call the timer callback which makes the PING_REQ.

View solution in original post

0 Likes
6 Replies
Phanindra_I
Moderator
Moderator
Moderator
250 sign-ins 10 likes given 25 likes received

Hi,

Would it be possible for you to use AWS as broker and see if you still observe this issue? Meanwhile, I will try to reproduce this on my side by following the steps that you mentioned.

Thanks

MattTreiber
Level 3
Level 3
25 sign-ins 10 replies posted 10 sign-ins

Hi,

I have tested it on an AWS instance our office has and I observed the disconnect as well. In this case, it took publishing to the client three times for the PINGREQs to stop and be disconnected:

 

MQTT client 'psoc6-mqtt-client7845' connecting to MQTT broker 'XXX.XXX.XXX.XXX'...

 

MQTT connection successful.

MQTT client subscribed to the topic 'ledstatus' successfully.

Press the user button (SW2) to publish "TURN ON"/"TURN OFF" on the topic 'ledstatus'...

  Subsciber: Incoming MQTT message received:

    Publish topic name: ledstatus

    Publish QoS: 1

    Publish payload: TURN ON

  Subsciber: Incoming MQTT message received:

    Publish topic name: ledstatus

    Publish QoS: 0

    Publish payload: TURN OFF

  Subsciber: Incoming MQTT message received:

    Publish topic name: ledstatus

    Publish QoS: 0

    Publish payload: TURN ON

 

Unexpectedly disconnected from MQTT broker!

Initiating MQTT Reconnection...

 

MQTT client 'psoc6-mqtt-client58200' connecting to MQTT broker 'XXX.XXX.XXX.XXX'...

MQTT connection successful.

Press the user button (SW2) to publish "TURN ON"/"TURN OFF" on the topic 'ledstatus'...

MQTT client subscribed to the topic 'ledstatus' successfully.

Phanindra_I
Moderator
Moderator
Moderator
250 sign-ins 10 likes given 25 likes received

Hi,

I have tested the MQTT CE on 43012 eval board with QoS=0. I have published good amount of messages. Since QoS=0, there are instances of multiple transmissions, erroneous reception but I haven't seen any disconnection like you mentioned. You can check out the logs attached to verify the same.

Thanks

MattTreiber
Level 3
Level 3
25 sign-ins 10 replies posted 10 sign-ins

Thank you for looking into this. I've repeated the experiment two more times. I primarily work in MacOS and created a new MQTT client using the GUI and it would still disconnect. Sometimes after the first publish to the client and sometimes after as many 8 or publish messages to the client. I see from your logs that you had a mix of the demo publishing and publishing to it at least 20 times each.

To remove my Mac from the equation, I also went through the same process above on a Windows machine with a fresh install of ModusToolbox 3.0, created the MQTT Client demo project, and with only changing the connection details and shortening the MQTT_KEEP_ALIVE_SECONDS value to 5 seconds it was disconnected after publishing to it only three times.

So it does not disconnect every time it is published to, but with the keep alive being 5 seconds, I do not have to wait long for a disconnection.

To get my mosquitto broker out of the way, I also tested with the test.mosquitto.org broker that the demo project is set to. To rule out anyone else publishing to the ledstatus topic on this public server, I changed the topic to ledstatus123456789. I saw a disconnect after the first publish to the device:

 

MQTT client 'psoc6-mqtt-client22965' connecting to MQTT broker 'test.mosquitto.org'...

MQTT connection successful.

MQTT client subscribed to the topic 'ledstatus123456789' successfully.

Press the user button (SW2) to publish "TURN ON"/"TURN OFF" on the topic 'ledstatus123456789'...

  Subsciber: Incoming MQTT message received:

    Publish topic name: ledstatus123456789

    Publish QoS: 0

    Publish payload: TURN ON

Unexpectedly disconnected from MQTT broker!

Initiating MQTT Reconnection...

MQTT client 'psoc6-mqtt-client63600' connecting to MQTT broker 'test.mosquitto.org'...

MQTT connection successful.

Press the user button (SW2) to publish "TURN ON"/"TURN OFF" on the topic 'ledstatus123456789'...

MQTT client subscribed to the topic 'ledstatus123456789' successfully.

 

If Infineon has a public AWS broker  to test with, I'd be happy to.

0 Likes
HarperWalters
Level 1
Level 1
First like received First reply posted Welcome!

Have you managed to solve the problem? I'd be grateful if you kept us updated about it. Still, if it's been resolved, I'd like to ask if you've tried using QOS 2 and keeping all the keepalive parameters and other settings "as is"? The broker won't disconnect because MQTT QoS 2 will require the exchange of data packets. It will be processing other data packets from and to the broker. So, I'd like you to check those settings ASAP because it may be helpful. Anyway, keep us updated on your issue. Best wishes.

I have been able to find a fix in ensuring that when publishing to the client the QoS should match what the client is expecting. In our case, we control both ends of the design so this is not an issue for us. 

I did program the client to expect QoS of 2, but when publishing to the client with a QoS of 0 or 1 when it expects 2, it will still occasionally disconnect.

So when there is a mismatch, the FreeRTOS timer used to send the PING_REQ does not call the timer callback which makes the PING_REQ.

0 Likes