PolarSSL is now part of ARM Official announcement and rebranded as mbed TLS.

Running ssl_server2 with 512 byte max_frag_len and HTTP LONG_RESPONSE

Oct 14, 2017 00:34
Chris Slothouber


I've been testing out mbedTLS with an aim to integrate it into an existing application. So far, it's been a real joy to work with. One question popped up when testing out ssl_server2 configured as DTLS. Extending the HTTP_RESPONSE by uncommenting LONG_RESPONSE on line 161 and imposing a max fragment length via mbedtls_ssl_conf_max_frag_len( &conf, MBEDTLS_SSL_MAX_FRAG_LEN_512 ) results in the following error:

Write to client:ssl_tls.c:7162: |2| => write ssl_tls.c:7084: |1| fragment larger than the (negotiated) maximum fragment length: 615 > 512 ssl_tls.c:7190: |2| <= write failed ! mbedtls_ssl_write returned -28928

Last error was: -28928 - SSL - Bad input parameters to function

My assumption based on this error is that the max_frag_len controls only the fragmentation negotiation, and I am responsible for splitting up any outgoing data via mbedtls_ssl_write(). Is my assumption correct?

Oct 15, 2017 13:46
Ron Eldor

HI Chris,
Your assumption is correct. As mentioned in the documentation:

 * \note           If the requested length is greater than the maximum
 *                 fragment length (either the built-in limit or the one set
 *                 or negotiated with the peer), then:
 *                 - with TLS, less bytes than requested are written.
 *                 - with DTLS, MBEDTLS_ERR_SSL_BAD_INPUT_DATA is returned.
 *                 \c mbedtls_ssl_get_max_frag_len() may be used to query the
 *                 active maximum fragment length.

In addition, note that Mbed TLS knows how to reassemble fragmented message, but it does not fragment the messageses, as commented here
Mbed TLS Team member