esp_at: large DTLS handshake messages fail reassembly in passive mode (AT+CIPRECVTYPE=1)

[hasheddan]

Describe the bug

When interacting with a DTLS server using the esp_at WiFi driver with CONFIG_WIFI_ESP_AT_PASSIVE_MODE=y, if the size of a reassembled DTLS handshake message exceeds 2048, mbedtls will frequently fail to complete the handshake because the portion of the UDP datagram which contains the second fragment will frequently be less than that of the DTLS message. This causes mbedtls to discard the record with a message like the following:

[00:06:33.144,592] <err> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3895: Datagram of length 743 too small to contain record of advertised length 849.

This occurs because CIPRECVDATA_MAX_LEN is hard-coded to ESP_MTU, which is hard-coded to 2048, so if the sum of the fragments exceeds 2048 they won't both be able to be read in a single operation by mbedtls.

Consider the following sequence of datagrams from the server:

The first datagram containing the Server Hello has length 80:

The second containing the first fragment of the Certificate has length 1225:

Because CIPRECVDATA_MAX_LEN is 2048, we only have room for 743 bytes (2048 - 80 - 1225 = 743), but the first DTLS message (the second fragment) in the datagram indicates in its header that it alone is 849 bytes (836 bytes + 13 header bytes):

To Reproduce

Connect to a DTLS server that fragments records during the handshake with CONFIG_WIFI_ESP_AT_PASSIVE_MODE=y set on client.

The following config will assist in observing the behavior via logging:

CONFIG_WIFI_LOG_LEVEL_DBG=n
CONFIG_NET_SOCKETS_LOG_LEVEL_DBG=y
CONFIG_MBEDTLS_LOG_LEVEL_DBG=y
CONFIG_MBEDTLS_DEBUG=y

Expected behavior

Manually increasing the CIPRECVDATA_MAX_LEN allows the handshake to complete successfully (I set to 4096), so one option would be to expose it as a user configurable value. Alternatively, higher levels of the stack may be able to handle ensuring that multiple records are identified.

Impact

Using the esp_at driver in passive mode is not possible in some scenarios with some servers.

Logs and console output

Shown above.

Environment (please complete the following information):

• Zephyr 3.7.0
• mbedtls at commit 2f24831ee13d399ce019c4632b0bcd440a713f7c

[hasheddan]

Though a handshake can still be completed in active mode, in Zephyr v3.7.0 this precludes the use of Zephyr's DNS resolution as it uses recvfrom, which is not implemented for active mode. However, @mniestroj has implemented it for active mode on main: 460b111