onboarding failure if called from discovery callback

[WAvdBeek]

onboarding failure if called from discovery callback Hello,

I'm having a strange issue... the onboard process is failing if I do the provisioning from the callback (real use case were I do auto onboard a server) I was able to reproduce the probleme on linux by modifying the onboarding tool.... The modifications were done so that the following is done: 1- onboarding tool displays the menu and we select 1 - discover unowned device 2- we make sure only one server is discoverable. The obt tool will discover the server and immediately do otm_just_works() 3- uppon success, the modified obt tool do a discovery of owned devices automatically 4- a call to provision_ace2() is done... and we end up with a TLS handshake error

mbedtls_log: ../../deps/mbedtls/library/ssl_srv.c:1262: client hello v3, message type: 21 mbedtls_log: ../../deps/mbedtls/library/ssl_srv.c:1267: bad client hello message ERROR: ../../security/oc_tls.c <read_application_data:1956>: oc_tls: mbedtls_error: SSL - Processing of the ClientHello handshake message failed DEBUG: ../../security/oc_tls.c <oc_tls_free_peer:303>: oc_tls: removing peer mbedtls_log: ../../deps/mbedtls/library/ssl_tls.c:8980: => free mbedtls_log: ../../deps/mbedtls/library/ssl_tls.c:9045: <= free

Here is the modified obt tool to reproduce. Just start the server and do a discover unowned device: obt.diff

Drop or upload designs to attach

Linked issues 0

farid farid @farid · 2 months ago I think I've found the root cause. It is not the fact of calling the function from inside the callback... it is related to network latencies. And calling from the callback makes it almost always happen: The onboarding tool send a tls session close to the server... The server receives the close notify and send (twice) a close notify too... However, the onboarding tool already started a new session... and it receives a close notify from the sever in the middle of a handshake! Sometime it has no importance, but not always.

Now, about the fix, I have two points: 1- in oc_tls.c, every call to mbedtls_ssl_close_notify() are done twice... why? (maybe an old bug from an old mbedtls library?). I removed all the duplicated calls and added a call to mbedtls_ssl_session_reset() (not sure this call is needed or not, but depending on the version of the mbdedtls library, this may be necessary) 2- For the issue itself, when getting MBEDTLS_ERR_SSL_PEER_CLOSE_NOTIFY, I've commented the call to mbedtls_ssl_close_notify() and replaced it with a call to mbedtls_ssl_session_reset(). My concern here is that maybe we should still call mbedtls_ssl_close_notify() if the message is not MBEDTLS_ERR_SSL_PEER_CLOSE_NOTIFY...