Hi Андрей,

The behavior you describe is a bug. But there isn't enough information to tell whether the bug is in Mbed TLS, in asio-standalone, in some other third-party code, or in your application.

Some things to consider:

* Are you using blocking or non-blocking I/O? * Are you using TLS or DTLS? What protocol version, what cipher suite and what extensions are negotiated? * Does your application call mbedtls_ssl_write() and mbedtls_ssl_read() again with the same buffer if they return MBEDTLS_ERR_SSL_WANT_READ or MBEDTLS_ERR_SSL_WANT_WRITE? * Do you close the TLS connection if mbedtls_ssl_xxx() returns an error other than WANT_XXX (or XXX_IN_PROGRESS if you use these features)? * What is the value of MBEDTLS_SSL_MAX_CONTENT_LEN (or MBEDTLS_SSL_OUT_CONTENT_LEN if it's defined)? * What operating system are you using? * Is this a client or a server? What TLS stack does the other side run?

You'll give others the most chance to help you if you post small, complete code to reproduce the problem. I realize this may be difficult. A good intermediate way to see what is going on would be to post debug logs. To get debug logs, make sure that MBEDTLS_DEBUG_C is enabled and call these functions before opening the TLS connection:

mbedtls_ssl_conf_dbg(&ssl_conf, my_debug, stdout);     mbedtls_debug_set_threshold(2);

See https://tls.mbed.org/kb/how-to/mbedtls-tutorial for a sample version of my_debug().

Calls to bio_send() are shown in the logs as

=> flush output message length: %d, out_left: %d ssl->f_send() returned %d <= flush output

If they don't show expected numbers, the rest of the logs should give a clue as to why.

Hope this helps,