search

espressif / esp-aws-iot

AWS IoT SDK for ESP32 based chipsets
Apache License 2.0
256 stars 154 forks source link

[Feature Request] Implement Non-blocking TLS connections (CA-272) #165

Open txf- opened 1 year ago

txf- commented 1 year ago

Is your feature request related to an issue you've encountered? If so, please elaborate. Currently, with blocking connections achieving a reasonable timeout is fairly difficult for TLS receive operations. with a long timeout connections maintain better stability, however if there are no data to receive, any other operation is blocked from transmitting while esp_tls_conn_read() is blocked. If the timeout is reduced, there are issues maintaining connection stability and the connection is often dropped.

Describe the new feature request I would like non-blocking mode to be implemented in "network_transport.c" of the coreMQTT Port.

Describe other alternatives you've considered I've tried this solution suggested in the freeRTOS forums

I configured it to be non_block, however it never seems to finish handshaking, regardless of the timeout. I've seen someone mention that non-blocking mode of the ESP-TLS library is broken, but I can't find any other mention or bug report describing the problem.

MarkoRimacByteLab commented 1 year ago

@txf- Did you try non_block option with the latest Release 202210.01-LTS? I tried it out myself and it seems to be working for me.

I also increased the .timeout variable to the default one provided by ESP-TLS, 10s, and TLS handshake was then successfully established when I used my simulation of bad network environment. Prior to this, with the default .timeout = 1s, the TLS would never get established.

It would be nice to have these parameters as a configurable part of library.

txf- commented 1 year ago

Did you try non_block option with the latest Release 202210.01-LTS?

Yes, I did. With your configuration non_block works, more or less, TLS connections are still liable to be more frequently dropped, but in general it works pretty well. However, OTA works very badly with it enabled.

If I use otaconfigMAX_NUM_BLOCKS_REQUEST > 1, the TLS connection contantly drops. If I have blocking mode on, I can easily handle 8 requests at a time.

Thanks

Edit: Further testing shows that it drops connections when there is heavy traffic, either in reception or transmission.

txf- commented 1 year ago

As an addendum here are some things I captured when ESP-TLS drops the connection:

W (584806) mbedtls: ssl_msg.c:2866 0x3ffed4c0: mbedtls_ssl_flush_output() returned -26752 (-0x6880)

W (584807) mbedtls: ssl_msg.c:5766 0x3ffed4c0: mbedtls_ssl_write_record() returned -26752 (-0x6880)

W (584825) MQTTWrap: Error or timed out waiting for ack for publish message 3680. Re-attempting publish.
I (586018) esp-tls: connecting...

MQTTWrap is the wrapper which I use for publishing and subscribing to topics. It publishes then blocks and waits for the coreMQTT-Agent stack to notify that the command has completed successfully

txf- commented 1 year ago

I should point out that this solution is partially implemented in https://github.com/FreeRTOS/iot-reference-esp32c3/issues/34 . There are some problems with the implementation but it mostly works.

I thought that I should reference it, in case anybody comes looking