2025-02-10 03:34 AM - last edited on 2025-02-10 03:57 AM by Andrew Neil
We have an application that uses LWiP and FreeRTOS.
The application has one UDP connection, for initial device discovery, which is managed through a UDP connection manager, on one FreeRTOS task. (Some by-the-by, background information)
We are using default LwIP 8 connection limit of 8 TCP connections, for the main application protocol.
The host side (PC) always opens, then closes a UDP device discovery probe connection first, then the main application TCP connection. Additionally the host application, may temporarily open a second TCP connection, only if a specialised configurator tool is used.
For this reason that the host application, may occasionally use two TCP connections, we have a FreeRTOS task, which is a connection manager, whose provides, opens & closes connections, in a round-robin queue/dequeue from the 8 TCP connections pool.
This connection manager, on a new UDP probe, closes any TCP connections left open in the queue, as a pre new TCP connection clean-up action.
Additionally the main task itself, is a HTTP server based, which runs in its own separate FreeRTOS task.
So the FreeRTOS tasks usage is...
Task A) UDP (device discovery) probe server
Task B) Connection manager, for 8 TCP connections
Task C) Main HTTP server based application, uses the pointer of the issued connection, from task B
I have observed with wireshark, that connection manager, 'should' be closing the connections FIN & FIN ACK transactions observed.
However, after 8 connect/disconnect cycles, the ninth connection locks up the device.
I've tried enabling SO_LINGER, and setting the LINGER time-out to 2000ms.
However, with the connection manager being in one task, and the main application being in another task,
I've started thinking it could be a connection closure thread safety issue possibly?
Anyone had any issues, with multiple TCP connections not being closed properly, and how did you resolve it?
2025-02-10 04:08 AM
This issues are very common with LWIP+FREERTOS - and also not easy to reproduce for debugging.
It does not come from a single bug, but many facotrs cooperate.
That is why I moved to AZRTOS + NetXDuo. not eror free but much more stable.