When data is received on TCP socket and the socket is subsequently closed (by the remote side), it is impossible to read the data even though HL7802 supports that.
In cellular_hl7802_api.c on line 1385 in function Cellular_SocketRecv, there is a check to cellularStatus which must pass for TCP_SOCKET_STATE_CONNECTION_UP. But the connection does not necessarily need to be “UP” to read the remaining data.
This interferes with another FreeRTOS library – the coreMQTT. When an MQTT connection is being set up (CONNECT packet is sent), the server may respond with CONNACK packet with error code. This error code would be properly handled in the coreMQTT library but the message is not read because the server (broker) also terminates the connection. So there is a race condition to receive the CONNACK before the modem reports the connection has been closed by the remote host. In my case (testing against Azure IoT Hub) sometimes no bytes are read, sometimes the first byte but never the whole CONNACK packet (4 bytes), which causes the coreMQTT library end on timeout instead on reporting the correct error.
I think it should be possible to read the remaining data and only impossible to send new data when a connection is closed.
Hello @kaktus, if your project is using FreeRTOS+TCP, I can answer it.
When the remote party closes the connection, it will set the FIN flag, accompanying the last couple of bytes.
FreeRTOS+TCP understands this, and it will deliver the bytes to the application.
One example is often seen in FTP: a file is sent from A to B, and as soon as the last bytes are sent, the FIN flag will go high.
( Sending zero bytes is even possible ).
The receiving end at FreeRTOS+TCP should keep on calling FreeRTOS_recv(), until it returns a negative value, which is not equal to -pdFREERTOS_ERRNO_EAGAIN or -pdFREERTOS_ERRNO_EINTR.
Maybe it is possible for you to attach a PCAP about the TCP conversation? And maybe you can give me an URL where I can find the implementation of Cellular_SocketRecv().
Hi @kaktus
Thanks for pointing out this. PR is created to fix that scenario and it’s currentls under review.
It allows HL7802 to read packets after remote disconnects.
I can pass same scenario in my local environment.