By the way, I notice you're using Mbed TLS 2.16.3. This version has
known bugs, including security issues. Please upgrade to the latest Mbed
TLS 2.16.x (currently 2.16.8, very soon 2.16.9) which is a security and
bugfix update, or to the latest release (2.24.0, soon 2.25.0) which has
all the latest bugfixes and features. Looking at the changelog, I don't
see any mention of a bug that could explain your problem, but I might
have missed something.
--
Gilles Peskine
Mbed TLS developer
On 09/12/2020 22:17, Сысоев Андрей via mbed-tls wrote:
> Hello.
>
> I need a little help with mbedtls 2.16.3.
> I'm using it under x86-64 with asio-standalone.
>
> Here's a standard situation:
> - I call mbedtls_ssl_write() to write let's say 8192 bytes of payload
> - it calls my own bio_send() with (8192+21) bytes as len parameter
> - bio_send() returns len=(8192+21), indicating transport data
> correctly written
> - mbedtls_ssl_write() returns 8192, indicating payload send
> GOOD: next I use this value to shift application buffer (erase first
> 8192 bytes), then send next chunk
>
> BUT after some time of running this situation happens:
> - once again, a call to mbedtls_ssl_write() to write let's say 8192
> bytes of payload
> - it calls bio_send() with smaller number, about 5500 bytes as len
> parameter (?? but OK)
> - bio_send() returns len=5500, indicating transport data correctly
> written
> - mbedtls_ssl_write() returns 8192 (??? why not 5500 ???), indicating
> payload send
> BAD: next I use this value to shift application buffer (erase first
> 8192 bytes), this leads to data loss of (8192-5500)=2692 bytes and
> ruins protocol
>
> As you can see, mbedtls_ssl_write() incorrectly reports about sent
> application data (8192 instead of 5500) - is this a bug? How can such
> situation happen under normal operation?
>
> Thanks in advance.
>