8 Sep
2022
8 Sep
'22
11:21 p.m.
Hi Martin,
Checking the history, the handling of the MTU doesn't seem to have changed since fragmentation support started in 2.13. At the time, I think handshake message fragmentation wasn't supported, but I don't see what difference setting ssl_context.handshake.mtu as opposed to ssl_context.mtu would have made for the handshake. (It would have caused the handshake to use a smaller MTU than application messages, but it's not clear why you'd want that.)
We can add a function to specifically set the handshake MTU if there's a use for it, but it's not clear to me what the use would be. Unless you can tell us why mbedtls_ssl_set_mtu() doesn't work for you, I think our answer is to just use that.
Best regards,
--
Gilles Peskine
Mbed TLS developer
On 19/07/2022 14:51, Martin Man via mbed-tls wrote:
> Hi guys,
>
> I use mbedtls for years (since 2.10 IIRC) upgrading to latest available as time goes by. For DTLS that is.
>
> I remember a case in the past where a link would have a small MTU (around 500 bytes) and I had to tune ssl_context.handshake.mtu to a lower value to successfully complete handshakes.
>
> I do not remember exactly why, but I did not want to actually restrict maximum value via mbedtls_ssl_set_mtu, maybe it was even ignored back then for handshakes… but
>
> Now when working on migration to 3.2.1 (gave some time to 3x releases to stabilize) I noticed that the whole ssl_context.handshake member is now private and inaccessible, which I guess is fine.
>
> Could somebody with more knowledge of the code recommend what is the best strategy for DTLS app where MTU may not always be 1400?
>
> thanks a lot for your time,
> Martin