Closed Resultfactory closed 7 years ago
We're looking at this now. The tlsio_mbedtls adapter does not properly implement the retrieveoptions method, which would cause the transport to develop this amnesia.
@Resultfactory - there is a fix checked into the latest master which implements the retrieveoptions call. I've tested the retrieveoptions call itself, but was not able to test your particular scenario. Please let us know if this does not do the trick. tlsio_mbedtls.c
Thanks, we tested this and it works.
Edit
Retrieveoptions and setoptions work, but the options that were set are not retrieved by (in our case) iothubtransport_mqtt_common before DisconnectFromClient is called. DisconnectFromClient then destroys the xio transport including all options.
@Resultfactory - I'm going to look into what's happening in the transport, and I'd like to follow your path as closely as possible. Can you point me to the sample that you're working from?
@JetstreamRoySprowl We used simplsample_mqtt
Hello, are there news about fixing this issue? I have the same one with TrustedCert option lost using azure-iot-sdk-c with MQTT.
This one is near the front of my queue, so it should be soon now (for a given value of "soon").
@dm2a : Are you also using tlsio_mbedtls?
Sorry for my late reply. I'm using tlsio_openssl.
I've found and fixed the problem in iothubtransport_mqtt_common.c, and it's moving through the checkin procedure now.
@Resultfactory @dm2a : The fix for this just got checked in.
retrieveoptions should be called right? I don't see a call to retrieveoptions in iothubtransport_mqtt_common.c We just tested the new sources. The fix does not work for us. How about you @dm2a ?
You don't have this line?
@JetstreamRoySprowl We use iothubtransport_mqtt_common.c from azure-iot-arduino. Do the sources in this repository still get updates?
[edit] The release cycle will start this Friday Sep 22, and will take a day or two. Sorry for the delay, @Resultfactory.
Hi, I've updated sources of the azure-iot-sdk-c to the release_2017_09_08 and, by now, cannot reproduce the issue. It seems to be solved. Thanks
@JetstreamRoySprowl It doesn't seem like the release cycle has completed. it doesnt look like this repository has gotten a update in a while actually.
@Resultfactory Yeah, the release is stalled while an issue with M0 is being resolved :-(. It's the next thing on my plate.
@JetstreamRoySprowl updated, thanks!
@Resultfactory Sadly the recent update still isn't quite up-to-date. I'm working on getting the current stuff released right now.
We updated the repositories, but the problem is not solved. The option handler fails to feed the options to the new xio?
D (246528) tlsio_mbedtls AzureIoTHubTask: tlsio_mbedtls_send -> 09:36:04 PUBLISH | IS_DUP: false | RETAIN: 0 | QOS: DELIVER_AT_LEAST_ONCE | TOPIC_NAME: devices/device/messages/events/ | PACKET_ID: 8 | PAYLOAD_LEN: 167 <- 09:36:04 PUBACK | PACKET_ID: 8 D (295658) xio_retrieveoptions: . D (295778) xio_retrieveoptions: . D (295898) xio_CloneOption: . D (296018) tlsio_mbedtls %s: Clone Option trusted cert success. heap: 50052, taskSHWM: 1368
The trusted cert option is cloned
D (296138) xio_CloneOption: . D (296268) tlsio_mbedtls AzureIoTHubTask: tlsio_mbedtls_send D (296388) xio_close: . D (296538) tlsio_mbedtls AzureIoTHubTask: tlsio_mbedtls_close D (296658) xio_close: . D (296788) socketio_lwip AzureIoTHubTask: Socket Closed in socketio_close -> 09:36:54 DISCONNECT D (296918) xio_destroy: . D (297038) tlsio_mbedtls AzureIoTHubTask: tlsio_mbedtls_destroy E (297168) socketio_lwip AzureIoTHubTask: Failure: socket state is not opened. D (297288) xio_close: . E (297408) tlsio_mbedtls AzureIoTHubTask: xio_send failed on_io_send D (297558) xio_close: . D (297688) xio_destroy: . D (297918) xio_create: . D (298038) tlsio_mbedtls %s: tlsio_mbedtls_create, heap: 82760, StackHWM: 1368, xio#: 3. D (298168) xio_create: . D (298298) socketio_lwip %s: socketio_create, heap: 84332, StackHWM: 1368, xio#: 3. D (298428) tlsio_mbedtls %s: mbedtls_init D (298558) xio_setoption: . D (298718) xio_setoption: .
Error: Time:Fri Nov 17 09:36:56 2017 File:/home/fhfs/ESP/BEASTv3/components/azure_iot/./optionhandler.c Func:OptionHandler_FeedOptions Line:234 failure while trying to _SetOption Error: Time:Fri Nov 17 09:36:56 2017 File:/home/fhfs/ESP/BEASTv3/components/azure_iot/./optionhandler.c Func:OptionHandler_FeedOptions Line:236 underlying_io_options Error: Time:Fri Nov 17 09:36:56 2017 File:/home/fhfs/ESP/BEASTv3/components/azure_iot/./xio.c Func:xio_setoption Line:194 unable to OptionHandler_FeedOptions Error: Time:Fri Nov 17 09:36:56 2017 File:/home/fhfs/ESP/BEASTv3/components/azure_iot/./optionhandler.c Func:OptionHandler_FeedOptions Line:234 failure while trying to _SetOption Error: Time:Fri Nov 17 09:36:56 2017 File:/home/fhfs/ESP/BEASTv3/components/azure_iot/./optionhandler.c Func:OptionHandler_FeedOptions Line:236 concreteOptions Error: Time:Fri Nov 17 09:36:56 2017 File:/home/fhfs/ESP/BEASTv3/components/azure_iot/./iothubtransport_mqtt_common.c Func:GetTransportProviderIfNecessary Line:1579 Failed feeding existing options to new TLS instance.
The options do not get put back.
D (299028) xio_open: . D (299148) tlsio_mbedtls AzureIoTHubTask: tlsio_mbedtls_open D (299278) xio_open: . D (299438) socketio_lwip AzureIoTHubTask: Opened socketio_open:499 D (299558) tlsio_mbedtls AzureIoTHubTask: on_underlying_io_open_complete D (299688) tlsio_mbedtls AzureIoTHubTask: on_underlying_io_open_complete D (300678) tlsio_mbedtls AzureIoTHubTask: Handshake completed in 870, on_underlying_io_open_complete D (300838) tlsio_mbedtls AzureIoTHubTask: tlsio_mbedtls_send -> 09:36:58 CONNECT | VER: 4 | KEEPALIVE: 240 | FLAGS: 192 | USERNAME: | PWD: XXXX | CLEAN: 0
We are able to reconnect because of our own workaround for setting the trusted cert.
@JetstreamRoySprowl With which xio platform was this tested? I see that for arduino setoptions are not implemented, and I would like to compare a tested/working source with our tlsio.
@Resultfactory I had to test the tlsio_mbedtls with a modified version of socketio_berkeley.c. I didn't save it, though.
When a timeout occurs in the connect message of iothubtransport_mqtt_common. The DisconnectFromClient function will call xio_destroy(). In our case the xio is tlsio_mbedtls. This destroy call frees the cacert which was set by a IoTHubClient_LL_SetOption(_handle,"TrustedCerts",cert) call at the initialization of the IoTHubClient. After which the IoTHubClient cannot reconnect to Azure because of a missing certificate.
Log File contains a situation where we were connected, an error occured, a connect message was sent, that message timed out, and the cacert was lost. The system was still connected to the internet and had a active connection to a web server when this happened.
How can we ensure that the IoTHubClient can retain the cacert set by SetOption, and properly reconnect to the AzureIoTHub.