NXD_MQTT_CONNECT_FAILURE when trying to connect to IoTHub

[Sagentia-KWC1]

Describe the bug Migrating to NetXDuo 6.2 from NetXDuo 6.1/Preview Struggling to get our device connected to IoTHub using TLS. It's failing when creating a TLS Session, throwing [ERROR] IoTHub client connect fail: MQTT CONNECT FAIL status: NXD_MQTT_CONNECT_FAILURE, subsequently with a DNS RESOLVE ERROR = NX_DNS_QUERY_FAILED.

Please also mention any information which could help others to understand the problem you're facing:

• What target device are you using? Using Azure NetX Duo STM32F767bitx using an External Modem (utilizing a Quectel BG95/96)
• Which version of Azure RTOS? Azure RTOS - 6.2.0 - https://github.com/azure-rtos/netxduo/tree/master/addons/azure_iot/samples
• What toolchain and environment? STM32IDE, development is done on Windows.
• What have you tried to diagnose or workaround this issue? We have been in touch with Microsoft Support and followed steps to verify that our device's clock is synced, that we are using TLS 1.2, and that the certificates we are using is correct. Have also looked at https://github.com/azure-rtos/netxduo/issues/86 and tried the recommeneded solutions in that thread.

While debugging, we have noticed that when creating a TLS session (_nx_secure_tls_session_start, line 75 of nx_secure/src/nxe_secure_tls_session_start.c ) [1], after the initial client introduction/hello message, raising an event. Consequently, this event resets or ends the TLS session (handled here:_nx_cloud_thread_entry, line 42 of cloud/nx_cloud.c) [2] even though the function (_nx_secure_tls_send_handshake_record, line 79 of nx_secure/src/nx_secure_tls_send_handshake_record.c, called at line 174 in [1]) returns NX_SUCCESS, causing the handshake to fail. We’re still trying to figure out why the reset is being fired.

To Reproduce Steps to reproduce the behavior:

1. Build my project in STM32Cube IDE
2. Flash onto device
3. Sync device time using SNTP Client
4. Start IoTHub Client and connect to IoTHub
5. Get [ERROR] IoTHub client connect fail: MQTT CONNECT FAIL status: NXD_MQTT_CONNECT_FAILURE

Expected behavior Expected a succesfull Connection to IoTHub, register our device, then trigger an Azure Device Update agent.

Impact Not being to connect to iot hub is a severe blocker/showstopper

Logs and console output Can only supply a .txt file containing the response we receive from Azure at the moment. azure_response.txt

Additional context Our IoTHub is currently on DigiCert2 so we are only supplying the Digicert Global Root G2 and Microsoft RSA Root Certificate Authority 2017. We built our code on top of this sample https://github.com/azure-rtos/netxduo/tree/master/addons/azure_iot/samples with a modified driver to fit our needs.

[Sagentia-KWC1]

Hi, any thought on this?

Here's a text file of the console output. ConsoleOutput.txt

[bo-ms]

Hi @Sagentia-KWC1 Sorry for the late reply, from console output, looks you started ADU agent before the connection is established. Before testing DigiCert2, did you test IoT Hub with DigiCert Baltimore Root successfully?

[INFO] Azure IoT Security Module has been enabled, status=0

Connected.

[ERROR] ADU agent start fail: IOTHUB NOT CONNECTED

[ERROR] IoTHub client properties request failed with error 131084

Properties request failed!: error code = 0x0002000c

IoTHub Host Name: watts-iot-hub.azure-devices.net; Device ID: W2-999-GF.

Connecting to iot hub client

[Sagentia-KWC1]

Hi @bo-ms.

We have tried Baltimore Root and could not get that to succesfully establish a connection either. Though the Baltimore Rootit worked in the past before when the SDK was still in preview but we relied on THREADX wifi (nx_wifi.c/h) instead of supplying a driver instance and we also used nx_azure_pnp_client instead.

We do check for a connected event flag before starting the ADU agent, not entirely sure why the device thinks it's connected - will look into this.

[Sagentia-KWC1]

Hi @bo-ms using the older SDK (?) with THREADX wifi and nx_azure_pnp_client we're able to connect to the IoTHub using the same certs, however, the device does not show up under Updates even though we have tagged it as "ADUGroup: $name". Do you know what the issue is here? (We used to rely on adding the groups manually however that is no longer possible)

[bo-ms]

Hi @Sagentia-KWC1 could you check following steps? thanks.

1. Make sure you already configure access control roles, https://learn.microsoft.com/en-us/azure/iot-hub-device-update/configure-access-control-device-update?tabs=portal
2. Try to add ADU group name when the device is connecting.
3. Suggest using the latest source code 6.2.1. We may help to check it if you still have the cert issue.
4. If you still cannot add ADU group, could you share the device twin information?

[bo-ms]

@Sagentia-KWC1 Closing as no response, feel free to re-open or create new issue if you have further issues.