Skip to main content
Associate II
August 26, 2026
Question

ST87M01 MTU or network issue during TLS Client Hello?

  • August 26, 2026
  • 2 replies
  • 37 views

Hi,

A bare-metal solution using the ST87M01-1301 modem (FW: v2.9.0) and a TCP connection to a remote server, with mbedTLS handling the TLS. 

We are experiencing an issue with one specific server (which is not under our management, making it very difficult to obtain server-side logs). The server does not respond to our TLS Client Hello at all. It does not send a TLS alert or close the connection; it simply leaves the socket open until our application timeout terminates the connection after 2 minutes.

Here is what we have verified and tested so far:
* The exact same Client Hello payload was copied and tested from a PC, and the server responds correctly with a Server Hello.
* The exact same bare-metal implementation works with three other remote servers.
* +CGCONTRDP reports an MTU of 1500. We have attempted to lower the "max_ip_frame_size" on the ST87M01 from 1600 down to 512 bytes, but it had no effect.
* During PC test, if we transmit an invalid Client Hello, the server immediately terminates the connection. However, on the bare-metal setup over the LTE-M network, even an invalid Client Hello payload results in the same continuous hang (but please look at the next point *).

* On the bare-metal setup, if the transmitted data does not start with valid TLS handshake bytes (such as 0x16), the server immediately terminates the connection. This confirms that the data is reaching the server over LTE-M?
* The Client Hello size is 197 bytes + the Record header.

Could this be a network/server or routing issue specific to the LTE-M network, or is there a specific configuration we should adjust/try on the modem?

Below is a snippet of our debug logs. Any insights or recommendations would be highly appreciated.

Best regards,
Henry

10:44:11.456  >>AT#RESET
10:44:11.456
10:44:11.456 OK
10:44:12.187
10:44:12.187 #REBOOT_HOST
10:44:12.385
10:44:12.385 #SIMST: 1
10:44:12.485
10:44:12.485 +CEREG: 2,"","",,,,"",""
10:44:13.876 Temperature: Value/Age/Valid: 0/34/0
10:44:15.929
10:44:15.929 +CEREG: 0,"","",,,,"",""
10:44:15.929
10:44:15.929 +CEREG: 2,"","",,,,"",""
10:44:18.546
10:44:18.546 +CGEV: ME PDN ACT 5
10:44:18.546
10:44:18.546 #IPCFG: 5,0,1
10:44:19.042
10:44:19.042 +CEREG: 1,"B542","0005916A",9,,,"",""
10:44:19.473
10:44:19.473 +CGEV: NW IP ADDR CHG 5
10:44:19.473
10:44:19.473 #IPCFG: 5,1,1
10:44:19.473 >>AT#SOCKETCREATE=5,0,TCP,50544,120,120,6
10:44:19.506
10:44:19.506 #SOCKETCREATE: 0
10:44:19.506
10:44:19.506 OK
10:44:19.506 >>AT#TCPCONNECT=5,0,******,443 // ****** was hostname
10:44:20.301
10:44:20.301 OK
10:44:20.301 TLS init OK
10:44:20.301 Current MbedTLS Epoch: 1787730114 //this was hard coded for faster testing
10:44:20.666 TLS Handshake Send...
10:44:20.699 >>AT#IPSENDTCP=5,0,2,16030300c5010000c10//..........
10:44:20.864
10:44:20.864 OK
10:44:21.626
10:44:21.626 #TCPACK: 5,0,202
10:45:20.573 Modem TLS Timeout: When: wait data! //our timeout
10:45:20.573 >>AT#SOCKETCLOSE=5,0 //here we close socket
....
12:15:09.431 >ATI
12:15:09.431
12:15:09.431 STMICROELECTRONICS
12:15:09.464 ST87M01-1301
12:15:09.464 A:2.9.0-M:2.9.0-S:2.9.0-G:2.9.0-B:1.1
12:15:09.464

 

2 replies

HenryKAuthor
Associate II
September 3, 2026

Hi,

Here is an update on the situation. I updated the ST87M01 modem to the latest firmware version (v2.11.0), which changed the behavior and revealed new clues:

With the new firmware, the modem started reporting received packets that exceed the configured limits of IP frame size when connecting to the “problematic” server. For example:

  • With max_ip_frame_size set to 1500: The modem reports up to #IPRECV: 5,0,2800

We tested lowering the max_ip_frame_size, with the following results:

  • max_ip_frame_size = 800: The maximum received size drops to 1520 bytes ( #IPRECV: 5,0,1520). With this setting, the TLS handshake successfully completes!
  • max_ip_frame_size = 512 The maximum received size drops to 944 bytes ( #IPRECV: 5,0,944).

Note: This behavior occurs only with this one specific server. With other public servers, the configuration works exactly as expected. For example:

  • With max_ip_frame_size = 1600, the other servers work fine and maximum was #IPRECV: 5,0,1400.
  • With max_ip_frame_size = 800, maximum was #IPRECV: 5,0,760.

BR.

Henry

Below is a snippet of our debug logs when max_ip_frame_size is 800.

15:11:12.355  >AT#IPPARAMS=1,0,65535,60,0,0.0.0.0,0000:0000:0000:0000:0000:0000:0000:0000,800,1
15:11:12.355
15:11:12.355 OK
15:11:16.463 >AT#RESET=1
15:11:16.562
15:11:16.562 OK
15:11:17.258
.....
15:12:33.394 >>AT#RESET
15:12:33.394
15:12:33.394 OK
15:12:34.123
15:12:34.123 #REBOOT_HOST
15:12:34.322
15:12:34.322 #SIMST: 1
15:12:34.421
15:12:34.421 +CEREG: 2,"","",,,,"",""
15:12:36.442
15:12:36.442 +CEREG: 0,"","",,,,"",""
15:12:36.442
15:12:36.442 +CEREG: 2,"","",,,,"",""
15:12:38.961
15:12:38.961 +CGEV: ME PDN ACT 5
15:12:38.961
15:12:38.961 #IPCFG: 5,0,1
15:12:39.425
15:12:39.425 +CEREG: 1,"B542","0005916A",9,,,"","11101001"
15:12:39.789
15:12:39.789 +CGEV: NW IP ADDR CHG 5
15:12:39.789
15:12:39.789 #IPCFG: 5,1,1
15:12:39.789 >>AT#SOCKETCREATE=5,0,TCP,50544,120,120,6
15:12:39.789
15:12:39.789 #SOCKETCREATE: 0
15:12:39.789
15:12:39.789 OK
15:12:39.789 >>AT#TCPCONNECT=5,0,******,443 // ****** was hostname
15:12:40.485
15:12:40.485 OK
15:12:40.518 TLS init OK
15:12:40.518 Current MbedTLS Epoch: 1788436323 // hard coded for testing
15:12:40.882 TLS Handshake Send...
15:12:40.882 >>AT#IPSENDTCP=5,0,2,16030300c5//..........
15:12:40.949
15:12:40.949 OK
15:12:41.247
15:12:41.247 #TCPACK: 5,0,202
15:12:41.810
15:12:41.810 #IPRECV: 5,0,1520
15:12:41.810 >>AT#IPREAD=5,0
15:12:41.975
15:12:41.975 #IPREAD: 5,0,1520
15:12:41.975
15:12:41.975
15:12:41.975 OK
15:12:43.499
15:12:43.499 #IPRECV: 5,0,1520
15:12:43.499 >>AT#IPREAD=5,0
15:12:43.665
15:12:43.665 #IPREAD: 5,0,1520
15:12:43.665
15:12:43.665
15:12:43.665 OK
15:12:44.659
15:12:44.659 #IPRECV: 5,0,1224
15:12:44.659 >>AT#IPREAD=5,0
15:12:44.791
15:12:44.791 #IPREAD: 5,0,1224
15:12:44.791
15:12:44.791
15:12:44.791 OK
15:12:47.044 TLS Handshake OK :D !!! // mbedTLS check OK
15:12:47.044 >>AT#SOCKETCLOSE=5,0 // just for testing....
ST Employee
September 4, 2026

Hi Henry, thank you for your message. Our team will come back to you shortly. KR,