Hi Ron,
This behavior can't be explained by the library code and the code you
posted alone. There has to be something wrong elsewhere.
Check that you aren't exceeding a limitation such as the stack size or
the size of executable and data sections. If it can be an issue on your
platform, check that load addresses are correct and sections don't
overlap. Make sure there's no overlap with any device memory mapping either.
Make sure that the whole binary is compiled with consistent settings.
The layout of mbedtls_ssl_context can be influenced by the Mbed TLS
configuration, so make sure that there's a single copy of
mbedtls/config.h and both Mbed TLS itself and your application were
built against that copy. The layout of mbedtls_ssl_context can also be
influenced by compiler settings on some platforms (e.g. structure
packing options), so make sure those are consistent across your build.
That's all I can think of for now. It may help to add a lot of printf
debugging with %p on various addresses, and compare these addresses with
what you know about memory mappings on that platform. Good luck!
--
Gilles Peskine
Mbed TLS developer
On 08/06/2021 19:16, Ron Eggler via mbed-tls wrote:
>
> On 2021-06-08 7:40 a.m., Ron Eggler via mbed-tls wrote:
>> On 2021-06-08 12:28 a.m., Gilles Peskine via mbed-tls wrote:
>>> Hi Ron,
>>>
>>> The code you've shown so far only consists of setup functions that
>>> populate fields in the configuration structure, then in the context
>>> structure. Communication has not started yet. mbedtls_ssl_set_bio in
>>> particular is a very simple setter function.
>>>
>>> Where does the code actually hang? Have some messages already been
>>> exchanged on the network at that point? Can you get a stack trace?
>>>
>>> Best regards,
>>>
>> Hi Gilles,
>>
>> Thank you for the response!
>>
>> I've inserted print statements after each of the setup functions and
>> can see that it never gets past mbedtls_ssl_set_bio. The messages
>> that have been exchanged, include the complete bring up and login of
>> the control channel, on the data channel, I call
>> mbedtls_x509_crt_init
>> mbedtls_pk_init
>> mbedtls_entropy_init
>> mbedtls_ctr_drbg_init
>> mbedtls_ssl_init
>> mbedtls_ssl_config_init
>> followed by the certificate and key file got parsing, seeding of the
>> RNG and that's where the previously mentioned procedure with
>> mbedtls_ssl_config_defaults() starts.
>> I unfortunately do not have a debugger available on that platform and
>> hence getting a stack trace won't be so straight forward. Do you have
>> any pointers as to what could be the issue potentially?
>>
>> Thank you,
>>
>> Ron
>
> Okay, I've made some further findings:
>
> I changed the mbedtls_ssl_set_bio funmction so that I inserted a print
> statement on entry and after every set line, like so:
>
> void mbedtls_ssl_set_bio( mbedtls_ssl_context *ssl,
> void *p_bio,
> mbedtls_ssl_send_t *f_send,
> mbedtls_ssl_recv_t *f_recv,
> mbedtls_ssl_recv_timeout_t *f_recv_timeout )
> {
> iprintf("mbedtls_ssl_set_bio::entry\n");
> ssl->p_bio = p_bio;
> iprintf("mbedtls_ssl_set_bio::p_bio set\n");
> ssl->f_send = f_send;
> iprintf("mbedtls_ssl_set_bio::f_send set\n");
> ssl->f_recv = f_recv;
> iprintf("mbedtls_ssl_set_bio::f_recv set\n");
> ssl->f_recv_timeout = f_recv_timeout;
> iprintf("mbedtls_ssl_set_bio::f_recv_timeout set\n");
> }
>
> and turns out, that I only see the very first print on
> "mbedtls_ssl_set_bio::entry\n" and nothing there after, which leads me
> to the believe that my *ssl is invalid which is odd as that variable
> is also used for ret = mbedtls_ssl_setup( &ssl_d, &conf_d ); and it is
> initialized at the beginning of the function with mbedtls_ssl_init(
> &ssl_d );
>
>
Gilles Peskine