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,