Hi Gilles,
thanks for the detailed explanation.
I think I figured out why I actually used only handshake mtu and not mbedtls_ssl_set_mtu.
In our app we support quick exchange of very little information over bluetooth backed link, and I think I saw the handshakes failing in cases where bluetooth lowered the MTU to around 512 bytes. And I definitely remember I saw handshakes not progressing. So I lowered the handshake mtu, and it fixed the problem, and I ignored the mbedtls_ssl_set_mtu or was afraid (read: did not understand what it does) to actually use it.
As you explained it, I think there is no need to expose it any further, and simply rely on mbedtls_ssl_set_mtu to properly configure all communication of a given session…
thanks for now for your help, Martin
On 8. 9. 2022, at 23:21, Gilles Peskine via mbed-tls mbed-tls@lists.trustedfirmware.org wrote:
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
-- mbed-tls mailing list -- mbed-tls@lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave@lists.trustedfirmware.org