Azure iot c sdk, backend disconnection sparodically due to no ping response

Hello @Hadi Deknache ,

Welcome to Microsoft Q&A .Thank you for reaching out to us.

The observed behavior is caused by network idle timeout mechanisms dropping inactive MQTT/TCP sessions during long telemetry gaps, with the SDK correctly detecting the condition and reconnecting when keep‑alive responses fail. Successful reconnection confirms that authentication and service availability remain intact.

Based on the logs and observed behavior, the intermittent disconnects are most consistent with network‑level idle connection termination combined with MQTT keep‑alive timing behavior.

The key indicators in the logs include:

• Mqtt Ping Response was not encountered
• IOTHUB_CLIENT_CONNECTION_NO_PING_RESPONSE

These messages indicate that the MQTT client sent a PINGREQ but did not receive a PINGRESP within the expected timeframe. When this occurs, the Azure IoT C SDK intentionally considers the connection unhealthy and performs an automatic disconnect followed by a reconnect. This behavior is expected by design and is used to safely recover from silent or half‑open TCP connections.

During the reconnect sequence, the SDK may temporarily report the connection state as UNAUTHENTICATED. This is a transient state while the MQTT session is being re‑established and does not indicate SAS token expiry or authentication failure. Authentication is automatically completed once the connection is recreated. A 24‑hour SAS token lifetime is sufficient and is not contributing to this behavior.

The most likely root cause in this scenario is:

• Network NAT or firewall idle timeout, or short‑lived network interruption combined with
• Long idle period between telemetry messages (10 minutes)

During these idle windows, intermediate network components—such as NAT gateways, firewalls, Wi‑Fi routers, or cellular networks—may silently close inactive TCP sessions. When the next MQTT keep‑alive exchange occurs, the session may already be partially or fully dropped, resulting in the missing PINGRESP and triggering a reconnect.

Please check if the following help -

1. Aligning MQTT keep‑alive with network behavior To reduce idle session termination:
   • Configure the MQTT keep‑alive interval to a value lower than any network idle timeout
   • Typical guideline ranges:
   • 30–60 seconds for cellular or unstable networks 60–120 seconds for stable enterprise networks
   Alternatively:
   • Introduce lightweight heartbeat telemetry between the 10‑minute data sends to keep the connection active
2. Ensuring proper SDK event loop execution When using the Azure IoT C SDK low‑level API:
   • Ensure IoTHubDeviceClient_LL_DoWork() is called frequently - recommended every 100 ms–1 s
   • Please avoid blocking operations that delay the event loop
   • Delays in this loop can prevent timely MQTT keep‑alive processing and lead to false disconnect detection
3. Validating network path behavior Please review the network path for:
   • NAT gateway idle session timeouts
   • Firewall or proxy TCP timeout policies
   • Cellular or Wi‑Fi power‑saving behavior
   • Intermittent packet loss affecting MQTT control packets
   These are common contributors to silent TCP session drops in IoT environments.
4. Enabling SDK diagnostics logging Consider enabling detailed SDK trace logging to observe:
   • MQTT PINGREQ / PINGRESP exchange timing
   • Reconnect triggers and reasons
   • Transport‑level warnings or delays
   This helps distinguish between:
   • Network‑level packet drops
   • Application‑level event loop delaysEnable detailed SDK trace logging to observe:
   • MQTT PINGREQ / PINGRESP exchange timing
   • Reconnect triggers and reasons
   • Transport‑level warnings or delays
   This helps distinguish between:
   • Network‑level packet drops
   • Application‑level event loop delays

The following references might be helpful , please check them out

• Monitor and Troubleshoot Azure IoT Hub Device Connectivity | Microsoft Learn
• Manage device reconnections to create resilient applications - Azure IoT | Microsoft Learn
• Use MQTT to communicate with Azure IoT Hub - Azure IoT Hub | Microsoft Learn
• https://github.com/Azure/azure-iot-sdk-c/blob/main/doc/Iothub_sdk_options.md - iot-hub-device-and-module-client-options

Thank you

Hello Hadi Deknache,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Azure IoT C SDK, backend disconnection sporadically due to no ping response.

The reconnect is expected SDK recovery behavior, but the reason for reconnect is not normal and must be corrected. IOTHUB_CLIENT_CONNECTION_NO_PING_RESPONSE means the MQTT keep-alive response was not received, so the Azure IoT C SDK closed the unhealthy MQTT connection and reconnected. - https://learn.microsoft.com/en-us/azure/iot-hub/iot-mqtt-connect-to-iot-hub, https://azure.github.io/azure-iot-sdk-c/md__home_runner_work_azure_iot_sdk_c_azure_iot_sdk_c_doc_connection_and_messaging_reliability.html

First verify whether the application uses the LL API. If it uses IoTHubDeviceClient_LL_*, then IoTHubDeviceClient_LL_DoWork() must be called continuously, at least every 100 ms. It is not called automatically for the LL API. If the application uses the non-LL convenience API, the SDK worker thread calls the lower-level work loop internally. https://azure.github.io/azure-iot-sdk-c/iothub__device__client__ll_8h.html

Set MQTT keep-alive explicitly to 60 seconds immediately after creating the client handle and before starting network operations:

int keepAliveSeconds = 60;
IoTHubDeviceClient_LL_SetOption(
    iotHubClientHandle,
    OPTION_KEEP_ALIVE,
    &keepAliveSeconds);

Also enable SDK trace logging:

bool traceOn = true;
IoTHubDeviceClient_LL_SetOption(
    iotHubClientHandle,
    OPTION_LOG_TRACE,
    &traceOn);

For the LL API, run:

while (app_running)
{
 IoTHubDeviceClient_LL_DoWork(iotHubClientHandle);
 ThreadAPI_Sleep(100);
}

If traces show that MQTT activity is delayed or missing, the root cause is the application not servicing DoWork() frequently enough. If traces show PINGREQ sent but no PINGRESP, investigate network/NAT/firewall/cellular/Wi-Fi idle timeout or packet loss, and test MQTT_WebSocket_Protocol over port 443 instead of MQTT over port 8883. - https://azure.github.io/azure-iot-sdk-c/md__home_runner_work_azure_iot_sdk_c_azure_iot_sdk_c_doc__iothub_sdk_options.html, https://learn.microsoft.com/en-us/azure/iot-hub/iot-mqtt-connect-to-iot-hub

To avoid consuming quota during reconnects, do not perform full state or twin resync after every reconnect. Cache the last reported state, retrieve desired properties after reconnect, compare versions/state, and send only changed reported properties. IoT Hub throttles device-to-cloud sends, twin reads, twin updates, and new device connections, so reconnect-triggered full resync can consume quota and cause throttling. - https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-quotas-throttling

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Hello @Hadi Deknache ,

Thank you for your patience while we were working on this.

The observed behavior, where intermittent disconnects occur with IOTHUB_CLIENT_CONNECTION_NO_PING_RESPONSE, is consistent with an MQTT keep‑alive response not being received in time. In such cases, the SDK correctly identifies the connection as unhealthy and performs an automatic reconnect. This recovery mechanism is expected; however, the frequency of reconnects can be reduced with proper alignment of configuration and environment.

Based on the understanding shared, the interpretation regarding DoWork() is largely correct with the following clarification.

The usage of DoWork() depends on the API layer:

Low-level (LL) API (IoTHubDeviceClient_LL_*)

• IoTHubDeviceClient_LL_DoWork() must be explicitly called by the application
• It is responsible for:
  • MQTT keep‑alive processing (PINGREQ/PINGRESP)
    • Message send/receive
      • Reconnection handling
• If not executed frequently, keep‑alive timing may be impacted
• Non-LL (convenience) API (IoTHubDeviceClient_*)
• A background worker thread is managed internally
  • No manual DoWork() call is required

Thus

1. DoWork() is only required in LL API
2. It is not invoked automatically in LL API
3. It is handled internally in non-LL API

The variation across devices indicates environmental differences rather than a single application defect. Contributing factors can include:

• Network idle timeout differences (NAT/firewall behavior)
• Cellular versus Wi‑Fi stability
• Packet loss or latency affecting MQTT control packets
• Device-side scheduling delays impacting DoWork() (LL API)
• Power-saving or network interface sleep behavior

Additionally, telemetry intervals (10 minutes) and heartbeat intervals (2 hours) create extended idle periods where intermediate network components may silently close TCP sessions. This increases the likelihood of missed keep‑alive responses.

Please check if the following help to stabilize the connection and reduce reconnect frequency:

1. Verifying SDK execution model
   1. Confirm whether LL or non-LL API is used
   2. If LL API is used, ensure continuous execution
2. Tuning MQTT keep‑alive
   1. Default keep‑alive for C SDK is configurable (~240 seconds)
   2. Recommended adjustment:
      • Use 60–120 seconds
      • Ensure value is lower than expected network idle timeout
3. Enabling diagnostic logging Helps identify root cause patterns:
   • PINGREQ not sent - application/event loop delay
   • PINGREQ sent but no PINGRESP - network-related issue
4. Validating network path Review:
   • NAT/firewall idle timeout policies
   • Cellular/Wi‑Fi stability differences
   • Packet loss affecting MQTT control messages
   If port 8883 is impacted, testing MQTT over WebSockets (port 443) can improve reliability.
5. Reducing quota consumption during reconnects Frequent reconnects can increase:
   • Message usage
   • Twin reads and updates
   • Resynchronization traffic
   To optimize:
   • Cache device state locally
   • Use twin versioning to send only incremental updates
   • Avoid full state resync after each reconnect

In summary ,

The reconnect behavior itself is expected, but the trigger (missed keep‑alive response) is influenced by a combination of network characteristics, idle intervals, and if using LL API event loop execution frequency. With proper tuning of keep‑alive settings, validation of DoWork() execution, and awareness of network conditions, the reconnect frequency and quota impact can typically be significantly reduced.

Thank you