HandleKeepAlive frequently calls MQTT_Ping

[xiaomizhouya]

When testing MQTT_ProcessLoop, we noticed a problem that MQTT_Ping was called frequently in the handleKeepAlive function, as shown in the red box in the figure, and every loop would come into this judgment logic. We found that in the SDK, when receiving a message from the server, pContext ->lastPacketTime does not change its value, which means that pContext ->lastPacketTime is always 0; When the current time exceeds PACKET-RX_TIMEOUT_S, it will continue to enter this logic and frequently send packets. Excuse me, is this a bug?

Also, I don't quite understand the logic of this logic. Why do I need to send ping packets based on the received message interval? My understanding is that sending ping packets based on the interval between the last message sent is sufficient. I hope to receive an answer.

Due to the above issue, we encountered a problem. We added log in the sdk and found that the device called sendBuffer function in MQTT_PING function to send data. When the return value is 2, can it indicate that the device has successfully sent data? However, according to the log of the server, no data packet was received from the device. I mean, what's the reason for this? Did the packet get lost in the network? May I ask if there is any log on the server side to assist us in debugging?

[aggarg]

We found that in the SDK, when receiving a message from the server, pContext ->lastPacketTime does not change its value, which means that pContext ->lastPacketTime is always 0;

It is updated here - https://github.com/FreeRTOS/coreMQTT/blob/main/source/core_mqtt.c#L1794.

My understanding is that sending ping packets based on the interval between the last message sent is sufficient. I hope to receive an answer.

It is needed for both idle Tx or Rx and the rationale is explained in this PR - FreeRTOS/coreMQTT#191.

When the return value is 2, can it indicate that the device has successfully sent data?

This means the transport interface told us that it has sent 2 bytes.

However, according to the log of the server, no data packet was received from the device. I mean, what's the reason for this? Did the packet get lost in the network? May I ask if there is any log on the server side to assist us in debugging?

How did you determine that no data was received on the server?

[xiaomizhouya]

So far, according to the client log, the sdk has successfully sent a 2bytes packet, but received no reply, and then returned to iot_core MQTTKeepAliveTimeout. We do not know if aws iot server received the data. We want to know what might cause this to happen and whether there is log support for debug on the server side.

[aggarg]

We want to know what might cause this to happen and whether there is log support for debug on the server side.

You can try this - https://docs.aws.amazon.com/iot/latest/developerguide/cloud-watch-logs.html.

I'd also suggest to capture network traffic from the device.

[xiaomizhouya]

thanks, I have an additional question to ask. We have found that there is a chance for the iot process to crash when executing MQTTDisconnect. By adding logs, we have discovered that there is a problem with the sendBuffer function. Have you encountered this problem before or have you solved it?

[aggarg]

We have found that there is a chance for the iot process to crash when executing MQTTDisconnect. By adding logs, we have discovered that there is a problem with the sendBuffer function.

Would you please describe the problem that you discovered? I do not understand the problem from the image you shared.

[xiaomizhouya]

By adding the log, we found that after the sdk enters the MQTT_Disconnect interface, the log only reaches line 3064, there is no log after that, and the iot_core process directly crashes, have you encountered this problem? This problem is not inevitable, I have tried seven or eight times encountered once.

[aggarg]

Thank you for explaining. No, we are not aware of any such issue. Would you please run the process in the debugger and see why is crashes?