Mbed TLS is now part of TrustedFirmware.org.

LWIP + embTls Possible corruption


Dec 18, 2017 16:44
Willy

Hello I am digging for a while now, with an issue in app using embTls + LWIP multithreaded. Our application works fine with on another platforms and another IP stack. LWIP seems to be ok with a test bench apart without embTls... We reproduce this issue using the version LWIP mainline and older versions 2.0.X Using LWIP, I always get a crash after LWIP shows some strange asserts Assertion "conn->current_msg->msg.w.offset < conn->current_msg->msg.w.len" failed at line 1596 in api_msg.c Assertion "conn->current_msg->msg.w.vector_cnt > 0" failed at line 1597 in api_msg.c Assertion "state!" failed at line 1776 in api_msg.c Assertion "conn->current_msg->msg.w.offset < conn->current_msg->msg.w.len" failed at line 1596 in api_msg.c

Is somebody already seen this issue? Is somebody know what those asserts means?

All feedback will be welcome Thanks by advance

 
Dec 19, 2017 07:35
Ron Eldor

HI Williy,
I believe you mean Mbed TLS.

I have some guideline questions: * Do you get any issue on Mbed TLS?
* Is the corruption happening in a TLS handshake?
* Have you set the correct bio calback functions in mbedtls_ssl_set_bio()?

I believe this is the assert upi are getting. The function documentation states:

/**
 * See if more data needs to be written from a previous call to netconn_write.
 * Called initially from lwip_netconn_do_write. If the first call can't send all data
 * (because of low memory or empty send-buffer), this function is called again
 * from sent_tcp() or poll_tcp() to send more data. If all data is sent, the
 * blocking application thread (waiting in netconn_write) is released.
 *
 * @param conn netconn (that is currently in state NETCONN_WRITE) to process
 * @return ERR_OK
 *         ERR_MEM if LWIP_TCPIP_CORE_LOCKING=1 and sending hasn't yet finished
 */

As much as I would like to help you more, I believe this issue is more related to your porting of Lwip.I would check your configuration of Lwip. If you think this is related to Mbed TLS, please state so, with your use case and scenario involving Mbed TLS.
Regards,
Mbed TLS Team member
Ron

 
Dec 19, 2017 13:19
Willy

Hello Ron Thanks for your feedback My app works and I can connect the server and make some transactions, it is a robustness trouble. My issue is for sure an issue with the porting with or the LWIP integration. Asserts occurs in LWIP but only when I connect the server using TLS. Connecting the server using only LWIP seems to be ok with several threads accessing the same server simultaneously. We have overloaded calloc/free and implemented threading_alt to support multi-threading. But after a 15 to 30 mn a corruption occurs in LWIP pbuff and I get some asserts that I don’t know the exact meaning, then de app crash. So, I just query this forum to check, if somebody has already experimented this kind if issue with a LWIP porting and if I can get some advices to fix my trouble. I will re-check lwipopt and Mbed TLS Again, any feedback/advices concerning the porting Mbed TLS + LWIP multithread is welcome

Regards Willy