-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Loss of wifi AP connection results in Azure/TLS errors on recovery (IDFGH-7210) (CA-220) #127
Comments
I have the exact same issue! Could somebody managed to avoid it? |
I switched to the Azure middleware for FreeRTOS. Worth the effort. https://github.com/Azure/azure-iot-middleware-freertos |
I was running into this same exact issue. Sometimes I'd get into this scenario even without turning off the AP. My device would just randomly disconnect and then never recover. The only workaround I was able to find was to modify a part of the MQTT code myself. Here's what that fix looks like (using my own fork of |
I have also the same issue but unfortunately this repo seems to be dead... |
@afcec Look into Azure middleware. They have a samples repo that has everything you need for getting up and running on any espressif device. https://github.com/Azure/azure-iot-middleware-freertos |
I just found a problem in tlsio_esp_tls.c
|
Environment
git describe --tags
to find it): 4.3.2xtensa-esp32-elf-gcc --version
to find it):// 1.22.0-80-g6c4433a
Problem Description
ESP32 on esp-idf 4.3.2
I've adapted the Azure example project into our project using the port stuff from the example. I'm testing different disconnection scenarios and if I have a controller up and running and connected to azure, then I power down the wifi AP, the controller loses connectivity as expected, but is never able to recover once reconnected.
Here's the log file from the disconnection event. It starts with a confirmation of a message sent to Azure IoT hub. Then the wifi disconnection happens, and right away there's a tls error, "esp-tls-mbedtls: read error :-76". I've seen this in other cases and when this happens Azure client is never able to recover. Later, there are errors about, "tlsio_esp_tls_send_async without a prior successful open". This repeats.
Once the wifi is plugged back in and started up, the controller will reconnect successfully to wifi AP, then throw a bunch more tls/azure errors, get an IP, then continue to throw the same tls and azure client errors. The controller is unable to recover from this and must be reset to get the Azure client working again.
Worth noting that this is tls specific. Standard http requests from this controller work fine once the wifi has reconnected.
Also notable is that the azure sdk never calls the connection status callback method set with IoTHubDeviceClient_LL_SetConnectionStatusCallback().
Expected Behavior
When wifi AP is lost, TLS should recover and Azure client should be able to reconnect
Actual Behavior
TLS cannot recover until Azure client attempts to renew SAS token
The text was updated successfully, but these errors were encountered: