ESP8266_RTOS_SDK use case: Handshake hard failure

Mbed TLS Bug Reports / Issues
1

I have a feeling this is actually:

  • platform specific category
  • actually an LWIP issue, not an mbedtls issue

However since I am unable to be fully sure of either, I’m fielding the question here.

I am trying to utilize the dtls_server example using (mostly) stock standard ESP8266_RTOS_SDK. However, during the handshake phase (specifically - seemingly - when we send the certificate) the system crashes and restarts.

I have copious notes, so rather than create a 100-page post, I’ll leave the summary of the issue here to start. Has anyone had success with dtls_server in this environment? Or, alternatively, has anyone encountered something like my issue?

Here’s a link to my test project: Bitbucket

2

Since it’s been two weeks, I’d like to ask, has anyone succeeded with dtls_server in any embedded environment? It seems we might be held up by DTLS cookie verification failing using built-in cookie write/verify · Issue #1124 · Mbed-TLS/mbedtls · GitHub

3

HI Malachi,
I apologize for delayed reply.
As mentioned in this issue:

The sample application were written as reference and tested on Linux and windows. Some of them require FS, some of them use the BSD sockets.
In order to make them work, you will need to adjust them to work on your platform.

There is not enough information to determine your crash root cause. Can you isolate where the crash occurs? Have you ported all the relevant platform functions?
A helpful article could be found here
Regards,
Mbed TLS Team member
Ron

4

Thank you for the response. I actually had never encountered that article about porting mbedtls. For my ESP8266 SDK environment:

  1. It does support the sockets API
  2. It provides its own net.c for mbedtls, though it’s basically sockets all over again
  3. Rolled my own code for timing.c. I think it works. I hope … :slight_smile:
  4. It’s reasonable to assume RTC/cert verification is in its disabled state. But not sure. ESP8266 does have some decent NTP support last I checked
  5. Debug logs seem to work quite well

As for the dtls_server.c itself:

  1. The crash seems to localize itself around the point where the handshake attempts to send the server certificate (ServerCertificate phase), after the ClientHello negotiation.
  2. The logs suggest that ClientHello , ClientHelloVerify, ServerHello themselves work without incident
  3. I’ve encountered scenarios where if I fiddle with max buffer sizes, #1 does not crash, but the certificate is never seen in tcpdump and openssl s_client, even though mbedtls & lwip logs indicate it did send (maybe exceeded MTU in this case?).
  4. Using test certificate, which mbedtls logs indicate to be ~2.5k

Handshake Messages are not fragmented as per MaxFragmentLength Extension Negotiation. · Issue #387 · Mbed-TLS/mbedtls · GitHub seems to indicate dtls-fragmenting of outgoing certificates isn’t fully supported. Wondering if that has any relation to what we’re experiencing…

5

So after intense trial and error, I am finally getting some indications that the issue may be in one of the following:

  • lwip
  • esp8266 native IP stack (most likely culprit)
  • power supply to the device

The crashes always start from deep inside the f_send call, from the native IP stack, which isn’t really the domain of mbedtls. I think it’s distantly possible that mbedtls rubs it the wrong way, but that seems unlikely

EDIT:

Further evidence suggests that the failure point is in IP Fragmentation implementation. Not directly an mbedtls issue, however if mbedtls implemented DTLS handshake fragmentation, then we wouldn’t need IP Fragmentation. I’ve read in a few places that feature is still underway.

6

Thank you for your update,
Yes, the fragmentation is still underway, but the good news is that it’s work in progress.