BG95-M5 TCPIP stuck in +QIOPEN: 1,566

We’re implementing a healthcheck using a remote server for our BG95-M5 application with firmware BG95M5LAR02A03_01.008.01.008 and in ECM mode.
For this we issue a HTTP GET every 5 minutes but after ~1 hour the server shows the socket being stuck in SYN_RECEIVED.

Correct requests go as follows for about 1 hour:
2025-07-01 11:44:21 - bg95 - DEBUG : >> AT+QICSGP=1
2025-07-01 11:44:21 - bg95 - DEBUG : << AT+QICSGP=1
2025-07-01 11:44:21 - bg95 - DEBUG : << +QICSGP: 3,“yourapn.m2m”,“”,“”,1
2025-07-01 11:44:21 - bg95 - DEBUG : << OK
2025-07-01 11:44:22 - bg95 - DEBUG : >> AT+CSQ
2025-07-01 11:44:22 - bg95 - DEBUG : << AT+CSQ
2025-07-01 11:44:22 - bg95 - DEBUG : << +CSQ: 26,99
2025-07-01 11:44:22 - bg95 - DEBUG : << OK
2025-07-01 11:44:23 - bg95 - DEBUG : >> AT+CEREG?
2025-07-01 11:44:23 - bg95 - DEBUG : << AT+CEREG?
2025-07-01 11:44:23 - bg95 - DEBUG : << +CEREG: 0,1
2025-07-01 11:44:23 - bg95 - DEBUG : << OK
2025-07-01 11:44:24 - bg95 - DEBUG : >> AT+QICFG=“viewmode”
2025-07-01 11:44:24 - bg95 - DEBUG : << AT+QICFG=“viewmode”
2025-07-01 11:44:24 - bg95 - DEBUG : << +QICFG: “viewmode”,0
2025-07-01 11:44:24 - bg95 - DEBUG : << OK
2025-07-01 11:44:25 - bg95 - DEBUG : >> AT+QICFG=“dataformat”
2025-07-01 11:44:25 - bg95 - DEBUG : << AT+QICFG=“dataformat”
2025-07-01 11:44:25 - bg95 - DEBUG : << +QICFG: “dataformat”,0,0
2025-07-01 11:44:25 - bg95 - DEBUG : << OK
2025-07-01 11:44:26 - bg95 - DEBUG : >> AT+QIACT?
2025-07-01 11:44:26 - bg95 - DEBUG : << AT+QIACT?
2025-07-01 11:44:26 - bg95 - DEBUG : << +QIACT: 1,1,1,“10.2.0.3”
2025-07-01 11:44:26 - bg95 - DEBUG : << OK
2025-07-01 11:44:27 - bg95 - DEBUG : >> AT+QISTATE=1,1
2025-07-01 11:44:27 - bg95 - DEBUG : << AT+QISTATE=1,1
2025-07-01 11:44:27 - bg95 - DEBUG : << OK
2025-07-01 11:44:28 - bg95 - DEBUG : >> AT+QIOPEN=1,1,“TCP”,“192.168.1.2”,80,0,0
2025-07-01 11:44:28 - bg95 - DEBUG : << AT+QIOPEN=1,1,“TCP”,“192.168.1.2”,80,0,0
2025-07-01 11:44:28 - bg95 - DEBUG : << OK
2025-07-01 11:44:28 - bg95 - DEBUG : << +QIOPEN: 1,0
2025-07-01 11:44:29 - bg95 - DEBUG : >> AT+QISTATE=1,1
2025-07-01 11:44:29 - bg95 - DEBUG : << AT+QISTATE=1,1
2025-07-01 11:44:29 - bg95 - DEBUG : << +QISTATE: 1,“TCP”,“192.168.1.2”,80,5217,2,1,1,0,“usbmodem”
2025-07-01 11:44:29 - bg95 - DEBUG : << OK
2025-07-01 11:44:30 - bg95 - DEBUG : >> AT+QISEND=1,179
2025-07-01 11:44:30 - bg95 - DEBUG : << AT+QISEND=1,179
2025-07-01 11:44:31 - bg95 - DEBUG : << >
2025-07-01 11:44:32 - bg95 - DEBUG : >> GET http://192.168.1.2/Server.Api/healthcheck
Get block
2025-07-01 11:44:32 - bg95 - DEBUG : << SEND OK
2025-07-01 11:44:32 - bg95 - DEBUG : << +QIURC: “recv”,1
2025-07-01 11:44:32 - bg95 - DEBUG : Expecting 0 bytes from +QIURC block
2025-07-01 11:44:33 - bg95 - DEBUG : >> AT+QIRD=1,500
2025-07-01 11:44:33 - bg95 - DEBUG : << AT+QIRD=1,500
2025-07-01 11:44:33 - bg95 - DEBUG : << +QIRD: 359
2025-07-01 11:44:33 - bg95 - DEBUG : Expecting 359 bytes from +QIRD block
2025-07-01 11:44:33 - bg95 - DEBUG : << [+QIRD payload 359 bytes]
2025-07-01 11:44:33 - bg95 - DEBUG : HTTP/1.1 200 OK
Content block
2025-07-01 11:44:33 - bg95 - DEBUG : << OK
2025-07-01 11:44:36 - bg95 - DEBUG : >> AT+QICLOSE=1,10
2025-07-01 11:44:37 - bg95 - DEBUG : << AT+QICLOSE=1,10
2025-07-01 11:44:46 - bg95 - DEBUG : << OK

After 1 hour all requests will fail on the AT+QIOPEN command with +QIOPEN: 1,566
At this time the server shows a TCP socket with SYN_RECEIVED and Wireshark shows the server responding with SYN+ACK. However the device keeps sending SYN requests and never ACK’s until it eventually times out and we get the +QIOPEN: 1,566 response.

Power cycling the modem or issuing AT+CFUN=0 and AT+CFUN=1 resolves the issue for ~1 hour. Keeping the socket open permanently also resolves the issue but this is not the preferred solution.

The modem is in ECM mode and performing the same healthcheck using the Linux network interface we’ve never had any issue’s with the exact same GET request. However we want to migrate this periodic healthcheck away from our application.

I think this incident is very strange, you try

AT+QICLOSE=1
AT+QIOPEN=xxx

Updating to firmware BG95M5LAR02A03_A0.206.A0.206 seems to have resolved the issue.
Devices have now been up for 48 hours with a healthcheck opening and closing the socket every 3 minutes.