Hello,
I’m experiencing issues completing the TLS handshake when using MbedTLS over the Sierra Wireless HL7812 modem via the AT command socket interface (UDP transport). The TLS stack is implemented on the application side (using Zephyr OS), and the modem acts purely as a transport via AT+KUDPCFG and related commands.
During the handshake phase (mbedtls_ssl_handshake()
), I encounter repeated MBEDTLS_ERR_SSL_WANT_READ
conditions, and eventually the process times out with:
Cannot connect UDP (-116)
From debug logs, it appears the modem does respond with incoming data, and I do call recv()
accordingly. However, MbedTLS logs show:
Next handshake message 0 not or only partially buffered
This seems to indicate the TLS record (e.g., ServerHello) was received only partially or wasn’t completely delivered to MbedTLS.
Relevant Excerpts from Logs:
-
MbedTLS requests 13 bytes:
in_left: 0, nb_want: 13 f_recv_timeout: 32000 ms
-
Application sends:
AT+KUDPRCV=2,60
-
Modem returns: 60 bytes data and
[00:00:52.936,000] <dbg> hl78xx_socket: offload_recvfrom: sending
41 54 2b 4b 55 44 50 52 43 56 3d 32 2c 36 30 0d |AT+KUDPR CV=2,60.
0a |.
[00:00:52.938,000] <dbg> hl78xx_socket: modem_pipe_callback: 376 modem_pipe_callback Pipe event received: 2
[00:00:52.949,000] <dbg> hl78xx_socket: modem_pipe_callback: 376 modem_pipe_callback Pipe event received: 1
[00:00:52.949,000] <dbg> hl78xx_socket: modem_process_handler: Processing handler - Bytes to read: 87, Collected: 0, Buffer size: 512
[00:00:52.949,000] <dbg> hl78xx_socket: modem_process_handler: 358 modem_process_handler 87 87 30
[00:00:52.988,000] <dbg> hl78xx_socket: modem_pipe_callback: 376 modem_pipe_callback Pipe event received: 1
[00:00:52.988,000] <dbg> hl78xx_socket: modem_process_handler: Processing handler - Bytes to read: 87, Collected: 30, Buffer size: 482
[00:00:52.988,000] <dbg> hl78xx_socket: modem_process_handler: 358 modem_process_handler 57 87 87
[00:00:52.988,000] <dbg> hl78xx_socket: on_cmd_sockread_common: Received Data:
0d 0a 43 4f 4e 4e 45 43 54 0d 0a 16 fe fd 00 00 |..CONNEC T.......
00 00 00 00 00 05 00 2f 03 00 00 23 00 00 00 00 |......./ ...#....
00 00 00 23 fe fd 20 ed 63 f9 ed f7 b7 f6 c8 9a |...#.. . c.......
17 bd 02 12 e2 cc 82 71 06 0e 92 db b3 26 5b be |.......q .....&[.
df 6a b2 ce 89 c2 03 2d 2d 45 4f 46 2d 2d 50 61 |.j.....- -EOF--Pa
74 74 65 72 6e 2d 2d |ttern--
[00:00:52.988,000] <dbg> hl78xx_socket: on_cmd_sockread_common: Processed Data
16 fe fd 00 00 00 00 00 00 00 05 00 2f 03 00 00 |........ ..../...
23 00 00 00 00 00 00 00 23 fe fd 20 ed 63 f9 ed |#....... #.. .c..
f7 b7 f6 c8 9a 17 bd 02 12 e2 cc 82 71 06 0e 92 |........ ....q...
db b3 26 5b be df 6a b2 ce 89 c2 03 |..&[..j. ....
[00:00:52.988,000] <dbg> hl78xx_socket: offload_recvfrom: 948 offload_recvfrom 0 60
[00:00:52.988,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_tls.c:4617: <= handshake
[00:00:52.988,000] <dbg> hl78xx_socket: offload_ioctl: 1163 offload_ioctl 258
[00:00:52.988,000] <dbg> hl78xx_socket: offload_ioctl: poll_prepare: fd=3, events=0x1
[00:00:52.988,000] <dbg> modem_chat: modem_chat_on_unknown_command_received: OK
[00:00:52.988,000] <dbg> modem_chat: modem_chat_log_received_command: +KUDP_RCV: "23.97.187.154" 5684
[00:00:52.988,000] <dbg> hl78xx_dev: hl78xx_on_udprcv: 361 3 [+KUDP_RCV: ] ["23.97.187.154"] [5684]
[00:00:58.101,000] <dbg> modem_chat: modem_chat_log_received_command: +KSTATEV: 2 1
[00:00:58.101,000] <dbg> hl78xx_dev: hl78xx_on_kstatev: KSTATEV: +KSTATEV: 2 1
[00:00:58.101,000] <dbg> hl78xx_socket: hl78xx_on_kstatev_parser: KSTATEV: socket 3 state 2
[00:00:58.101,000] <dbg> hl78xx_socket: hl78xx_on_kstatev_parser: Unhandled KSTATEV for socket 3 state 2
[00:01:10.566,000] <dbg> hl78xx_socket: offload_ioctl: 1163 offload_ioctl 259
[00:01:10.566,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_tls.c:4606: => handshake
[00:01:10.566,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2353: => flush output
[00:01:10.566,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2362: <= flush output
[00:01:10.566,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_tls.c:4525: client state: MBEDTLS_SSL_SERVER_HELLO
[00:01:10.566,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_tls12_client.c:1195: => parse server hello
[00:01:10.566,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:4189: => read record
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:4288: => ssl_load_buffered_message
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:4354: Next handshake message 0 not or only partially bufffered
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:4362: <= ssl_load_buffered_message
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2155: => fetch input
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2201: in_left: 0, nb_want: 13
[00:01:10.567,000] <inf> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2240: f_recv_timeout: 32000 ms
[00:01:10.567,000] <dbg> hl78xx_socket: offload_recvfrom: 840 offload_recvfrom
[00:01:10.567,000] <dbg> hl78xx_socket: offload_recvfrom: 948 offload_recvfrom 11 -1
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_tls.c:4617: <= handshake
[00:01:10.567,000] <dbg> hl78xx_socket: offload_ioctl: 1163 offload_ioctl 258
[00:01:10.567,000] <dbg> hl78xx_socket: offload_ioctl: poll_prepare: fd=3, events=0x1
[00:01:10.567,000] <dbg> hl78xx_socket: offload_ioctl: 1163 offload_ioctl 259
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_tls.c:4606: => handshake
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2353: => flush output
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2362: <= flush output
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_tls.c:4525: client state: MBEDTLS_SSL_SERVER_HELLO
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_tls12_client.c:1195: => parse server hello
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:4189: => read record
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:4288: => ssl_load_buffered_message
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:4354: Next handshake message 0 not or only partially bufffered
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:4362: <= ssl_load_buffered_message
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2155: => fetch input
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2201: in_left: 0, nb_want: 13
[00:01:10.567,000] <inf> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2240: f_recv_timeout: 32000 ms
[00:01:10.567,000] <dbg> hl78xx_socket: offload_recvfrom: 840 offload_recvfrom
[00:01:10.567,000] <dbg> hl78xx_socket: offload_recvfrom: 948 offload_recvfrom 11 -1
[00:01:10.567,000] <wrn> mbedtls_dbg: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_tls.c:4617: <= handshake
z_impl_zsock_connect: -1 116
[00:01:10.567,000] <err> net_lwm2m_engine: Cannot connect UDP (-116)
…and data is received, showing what looks like a TLS ServerHello record, ending in --EOF--Pattern--
.
- Despite that, the MbedTLS handshake does not progress, and the retry eventually fails.
My Questions:
-
Is there a known issue or limitation with how the HL7812 buffers or signals available UDP data, particularly in high-frequency operations like TLS handshakes?
-
Are there modem-side configuration parameters (buffer size, fragmentation, flow control) that could impact this behavior?
-
The log shows:
KSTATEV: socket 3 state 2
But this is unhandled by my driver. Is there documentation on what
KSTATEV: 2
means and how it should be handled in client code? during udp & tcp communication -
Could the modem’s URC/data handling introduce race conditions or delays that cause MbedTLS to timeout or misinterpret data availability?
Environment Details:
- Modem: HL7812 5.5.14.0
- Transport: UDP via AT+KUDPCFG
- TLS Stack: MbedTLS (Zephyr OS)
- AT Flow Control: RTS/CTS enabled
- Sleep Disabled: AT+KSLEEP=2
I have attached the full log if you are interested in:
serial-terminal-11052025_121627-lwm2m-fails.txt (588.6 KB)
I would appreciate any documentation, clarifications, or configuration advice you could offer for this situation. Happy to provide more logs or test specific workarounds if helpful.
Thank you!