Data stuck in modem until remote closes connection

guigui · June 4, 2025, 1:57pm

Hello,

I have a custom board with an HL7812 modem running FW HL7812.5.7.2.0
My application is connected to a TCP server. I have a problem where it looks like the data sent by the TCP server is stuck inside the modem until the server closes the connection and the app receives the +KTCP_NOTIF URC.

The server sends 3443 bytes to the client.
The client first gets a notification for 1629 bytes available and reads them in small chunks:

[  315.735000] +KTCP_DATA: 1,1629
[  315.736000] AT+KTCPRCV=1,2
[  315.798000] +KTCP_DATA: 1,1627
[  315.799000] AT+KTCPRCV=1,1
[  315.861000] +KTCP_DATA: 1,1626
[  315.862000] AT+KTCPRCV=1,2
[  315.924000] +KTCP_DATA: 1,1624
[  315.924000] AT+KTCPRCV=1,50
[  315.987000] +KTCP_DATA: 1,1574
[  315.988000] AT+KTCPRCV=1,1500
[  316.202000] +KTCP_DATA: 1,74
[  316.202000] AT+KTCPRCV=1,74

Then nothing happens, the client does not receive any more +KTCP_DATA URCs.
The AT+KTCPSTAT command shows that there is no pending data to read in the socket:

[  472.215000] AT+KTCPSTAT
[  472.215000] +KTCPSTAT: 1,3,-1,0,0

Finally 206 seconds later, the application receives the remaining bytes together with the URC showing that the remote has closed the connection:

[  522.611000] +KTCP_DATA: 1,1629
[  522.612000] AT+KTCPRCV=1,1500
[  522.826000] +KTCP_DATA: 1,129
[  522.826000] AT+KTCPRCV=1,129
[  522.889000] +KTCP_DATA: 1,185
[  522.952000] +KTCP_NOTIF: 1,4

The problem is repeatable and the first +KTCP_DATA URC always gives 1629 bytes.
I tried another board with a different modem connected to the same TCP server and this problem does not happen.

Is that a known issue? Is there something special about this 1629 number?

Thanks!

jyijyi · June 4, 2025, 2:02pm

how about using AT+KTCPSTART command?

guigui · June 4, 2025, 2:26pm

The whole code is built around AT+KTCPSND and AT+KTCPRCV. Testing AT+KTCPSTART would require some extensive changes. Is there any other way to debug this problem?

jyijyi · June 4, 2025, 3:03pm

guigui:

[  315.735000] +KTCP_DATA: 1,1629
[  315.736000] AT+KTCPRCV=1,2
[  315.798000] +KTCP_DATA: 1,1627
[  315.799000] AT+KTCPRCV=1,1
[  315.861000] +KTCP_DATA: 1,1626
[  315.862000] AT+KTCPRCV=1,2
[  315.924000] +KTCP_DATA: 1,1624
[  315.924000] AT+KTCPRCV=1,50
[  315.987000] +KTCP_DATA: 1,1574
[  315.988000] AT+KTCPRCV=1,1500
[  316.202000] +KTCP_DATA: 1,74
[  316.202000] AT+KTCPRCV=1,74

why did you read it in small chunk?
If you read it once, will there be any problem?

guigui · June 5, 2025, 7:41am

The same thing happens if I read all available data in one command with AT+KTCPRCV=1,1629. I don’t get any KTCP_DATA URC for the next data.

jyijyi · June 5, 2025, 7:58am

so problem only happens starting from 1629 bytes?
Have you asked server to send 1628 bytes?

guigui · June 5, 2025, 8:03am

Yes, the problem is only seen when the server sends more than 1629 bytes at once.
If the server sends smaller packets the application can read them without problems.

jyijyi · June 5, 2025, 11:26am

i cannot reproduce the issue with my server:


at+ktcprcv=3,1360
CONNECT
220-FileZilla Server 0.9.60 beta
220-written by Tim Kosse (tim.kosse@filezilla-project.org)
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-projec--EOF--Pattern--
OK

+KTCP_DATA: 3,1086
at+ktcp=3,1086
+CME ERROR: 4
at+ktcprcv=3,1086
CONNECT
t.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220-Please visit https://filezilla-project.org/
220 Please visit https://filezilla-project.org/
--EOF--Pattern--
OK
ati3
HL7812.5.5.14.0

OK

guigui · June 5, 2025, 11:38am

I also tried with a local TCP server and I don’t see the problem.

I see the problem when the application connects to Azure IoT Hub over TLS.
When the hub sends small TCP packets, the application can read them without any problems. However when the hub sends a large device twin patch, this is where the problem happens.

I will try with a TLS connection to a local server to see if this is happens also.

guigui · June 5, 2025, 2:20pm

I managed to reproduce the issue with a TLS connection to a local TCP server.
I generate a self-signed certificate with this command:

openssl req -x509 -newkey rsa:2048 -keyout server.key -out server.crt -days 365 -nodes

I run the TLS server with this python script:

import socket
import ssl
import time
import os

# Server configuration
HOST = '0.0.0.0'
PORT = 443         # Port to listen on
CERT_FILE = 'server.crt'  # Path to the server's certificate file
KEY_FILE = 'server.key'   # Path to the server's private key file

def generate_random_bytes(size):
    """Generate random bytes of the specified size."""
    return os.urandom(size)

def run_tls_server():
    # Create a regular socket
    server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    server_socket.bind((HOST, PORT))
    server_socket.listen(5)
    print(f"Server listening on {HOST}:{PORT}")

    # Accept connections
    with ssl.wrap_socket(server_socket, server_side=True, certfile=CERT_FILE, keyfile=KEY_FILE, cert_reqs=ssl.CERT_NONE) as tls_server_socket:
        print("Waiting for a connection...")
        client_socket, addr = tls_server_socket.accept()
        print(f"Connection established with {addr}")

        # Wait for 10 seconds
        print("Waiting for 10 seconds...")
        time.sleep(10)

        # Generate random bytes
        random_bytes = generate_random_bytes(2400)
        client_socket.sendall(random_bytes)
        print(f"Sent random bytes to {addr}")

        # Close the connection
        print("Waiting for 30 seconds...")
        time.sleep(30)
        client_socket.shutdown()


if __name__ == "__main__":
    run_tls_server()

I write the self-signed certificate to the modem with AT+KCERTSTORE
I select this cert with AT+KSSLCRYPTO=0,8,3,25392,12,4,1,0

// connection to the server
AT+KTCPCFG=1,3,\"IPADDRESSOFSERVER\",443,,,,0,0,0
+KTCPCFG: 1
AT+KTCPCNX=1
+KTCP_IND: 1

// the server sends 2400 bytes, we get an URC for 1629 bytes only
+KTCP_DATA: 1,1629
AT+KTCPSTAT
+KTCPSTAT: 1,3,-1,0,1629

// I read 1629 bytes
AT+KTCPRCV=1,1629
// no URC coming, no data pending to read in the socket
AT+KTCPSTAT
+KTCPSTAT: 1,3,-1,0,0

// server closes the connection, and the pending 771 bytes are never read
+KTCP_NOTIF: 1,4
AT+KTCPSTAT
+KTCPSTAT: 1,5,4,0,0

So it seems the issue is related to TLS client.
If the server sends less than 1629 bytes, the client can read them. Anything above 1629 is truncated and the remaining bytes are not received.

jyijyi · June 5, 2025, 4:00pm

is that no issue is found in AT+KTCPSTART command?

guigui · June 10, 2025, 7:23am

Same issue happens when using AT+KTCPSTART

jyijyi · June 10, 2025, 7:25am

Please contact distributor for this issue.
I have seen that this issue is fixed in HL7800, but not yet in HL781x.

Topic		Replies	Views
KTCP_DATA limit on HL7800? HL78	17	536	May 2, 2023
+KTCP_DATA with large data Legacy HL Series	3	775	November 14, 2023
[Hilo]max re-transmission time to send a packet data HL Series FAQ	0	1923	July 23, 2013
AT+KTCPRCV doesn't return any data (buffer has) Legacy HL Series	2	1478	May 12, 2017
TCP status on HL6528RD Legacy HL Series	9	724	January 21, 2020

Data stuck in modem until remote closes connection

Related topics