search

Azure / azure-iot-arduino

Azure IoT library for the Arduino
Other
168 stars 95 forks source link

SetOption TrustedCert lost in DiconnectFromClient #54

Closed Resultfactory closed 7 years ago

Resultfactory commented 7 years ago

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.

JetstreamRoySprowl commented 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.

JetstreamRoySprowl commented 7 years ago

@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

Resultfactory commented 7 years ago

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.

JetstreamRoySprowl commented 7 years ago

@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?

Resultfactory commented 7 years ago

@JetstreamRoySprowl We used simplsample_mqtt

dm2a commented 7 years ago

Hello, are there news about fixing this issue? I have the same one with TrustedCert option lost using azure-iot-sdk-c with MQTT.

JetstreamRoySprowl commented 7 years ago

This one is near the front of my queue, so it should be soon now (for a given value of "soon").

JetstreamRoySprowl commented 7 years ago

@dm2a : Are you also using tlsio_mbedtls?

dm2a commented 7 years ago

Sorry for my late reply. I'm using tlsio_openssl.

JetstreamRoySprowl commented 7 years ago

I've found and fixed the problem in iothubtransport_mqtt_common.c, and it's moving through the checkin procedure now.

JetstreamRoySprowl commented 7 years ago

@Resultfactory @dm2a : The fix for this just got checked in.

Resultfactory commented 7 years ago

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 ?

JetstreamRoySprowl commented 7 years ago

You don't have this line?

Resultfactory commented 7 years ago

@JetstreamRoySprowl We use iothubtransport_mqtt_common.c from azure-iot-arduino. Do the sources in this repository still get updates?

JetstreamRoySprowl commented 7 years ago

[edit] The release cycle will start this Friday Sep 22, and will take a day or two. Sorry for the delay, @Resultfactory.

dm2a commented 7 years ago

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

Resultfactory commented 7 years ago

@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.

JetstreamRoySprowl commented 7 years ago

@Resultfactory Yeah, the release is stalled while an issue with M0 is being resolved :-(. It's the next thing on my plate.

Resultfactory commented 7 years ago

@JetstreamRoySprowl updated, thanks!

JetstreamRoySprowl commented 7 years ago

@Resultfactory Sadly the recent update still isn't quite up-to-date. I'm working on getting the current stuff released right now.

Resultfactory commented 6 years ago

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.

Resultfactory commented 6 years ago

@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.

JetstreamRoySprowl commented 6 years ago

@Resultfactory I had to test the tlsio_mbedtls with a modified version of socketio_berkeley.c. I didn't save it, though.