Mqtt subscriber error

[Gustavo Junqueira]

I am experiencing an error that I can't figure it out why it is happening and where to go and try to fix it.

I am using the subscriber implementation on my nRF51, Raspberry Pi as router and broker.

To test it i'm using a python program on Raspberry to publish the "led/state" topic. I set the publisher to send a publish message every 0.5 seconds inside a loop to send 1200 packets, than it closes the connection.

I saw in wireshark that the broker send the publish message to the subscriber than the subscriber send Acknowledgement to the broker and the broker send an Acknowledgement to the subscriber.

So, around 1887 packets sent in this 3 way handshake, the subscriber stops executing and the broker disconnects it because of the timeout. But to get subscriber running again I have to restart and connect it again to the Rpi.

I ran this test publishing in many other ways and the subscriber halts every time around 1885 to 1890 packets.

Is there something on the mqtt code that I can change to not have this issue?

[Krishna Shingala]

Hello Gustavo,

There is no good reason in MQTT to stop exchanging packets after a while. I am however suspicious at the BLE level. Is it possible for you to capture BLE logs and notice if the Raspberry Pi is initiating a disconnection?

Thank you!

[Gustavo Junqueira]

Hi Krishna,

I tested here again and saw something that may be the problem. I saw that in some point, the Broker (Mosquito running on Raspberry Pi) send the publish to the BLE, the BLE Acknowledge it, but the Broker does not send the Acknowledge to the BLE on the 3 way handshake. After that, the Broker and BLE cannot talk correctly anymore and the Broker keeps retransmitting the messages and the BLE Acknowledging the wrong messages.

Now, I think the problem is with the mosquitto broker and not with the mqtt BLE.

[Krishna Shingala]

Hi Gustavo,

This is an interesting observation. When you say the Broker does not send the Acknowledge, do you mean TCP ACK si not sent by the broker? Also, eventually, does the TCP connection close between broker and client?

I am probing a bit at TCP level as that is another possible place where the communication between the broker and client can fail.

Regards, Krishna

[Gustavo Junqueira]

Hi Krishna, Yes, the Broker stops sending the TCP ACK for every publish message to the subscriber client. And send TCP ACK only to a few messages and then the Broker and the client desynchronise. The TCP connection does not close, the Broker keeps retransmitting the publish messages and the client keep trying to acknowledge the last message before the Broker starts to retransmit. I have some .pcap logs if you want to check out.

[Krishna Shingala]

Gustavo, at this point I am not able to nail down if the issue you report has a direct correlation with the time or the number of packets. I say time because there are timers needed for TCP connection to be kept alive. In order to rule the time factor out, is it possible that you change the KEEPALIVE time of MQTT client on the kit to either a very high value, and change the rate of publishing as well, may be one packet every second or so. After this change, please observe if the unexpected behavior occurs after about the same number of packets. If yes, then we ruled at any correlation with time. And then the problem is purely a function of number of packets.