Electronics > Microcontrollers

LWIP may get stuck in the select function

(1/3) > >>

tilblackout:
The system is using FreeRTOS and LwIP, and there is a sporadic issue where the program gets stuck in the select function.

My program uses two network interfaces, one for PPP dial-up to access the external network, and the other using Ethernet. I have two tasks that call select: one to monitor the read fd for all sockets, and another when writing data to Ethernet, to monitor its write fd. If the select call fails during the write operation, it suggests that LWIP may be running out of memory, and I refrain from writing.

After running the program overnight, it typically gets stuck after seven to eight hours, with both tasks stuck inside the select function. How can I pinpoint the issue, as it's difficult to reproduce and appears to be related to the non-reentrant nature of select?

I've noticed two macro definitions: LWIP_NETCONN_SEM_PER_THREAD and LWIP_NETCONN_FULLDUPLEX. Would enabling these macros help avoid this situation?

I have also observed that when a socket being monitored by select is closed by another task before the select call reaches its timeout, the socket cannot be properly reclaimed. Is this also related to these two macro definitions?

I would greatly appreciate the assistance you have provided. ;D

nctnico:
You need some kind of locking. You have to check the LWIP source code to see which locking mechanism select() uses and enable that. IIRC Lwip has two thread locking options but I don't know which does what.

ledtester:

--- Quote from: tilblackout on September 18, 2023, 09:09:39 am ---
I have also observed that when a socket being monitored by select is closed by another task before the select call reaches its timeout, the socket cannot be properly reclaimed. Is this also related to these two macro definitions?


--- End quote ---

Are you calling raw API functions from the other task? I found this at:

https://www.nongnu.org/lwip/2_1_x/multithreading.html


--- Quote ---lwIP started targeting single-threaded environments. When adding multi- threading support, instead of making the core thread-safe, another approach was chosen: there is one main thread running the lwIP core (also known as the "tcpip_thread"). When running in a multithreaded environment, raw API functions MUST only be called from the core thread since raw API functions are not protected from concurrent access (aside from pbuf- and memory management functions). Application threads using the sequential- or socket API communicate with this main thread through message passing.
...

--- End quote ---

There's a lot more multithreading advice on that page.

tilblackout:
Thanks for your reply.

The SDK example I'm using is based on FreeRTOS+LwIP, so the macro definitions you mentioned are already enabled. Everything is running smoothly without executing 'select' in multiple places. Last night, I enabled the two suspicious macro definitions, LWIP_NETCONN_SEM_PER_THREAD and LWIP_NETCONN_FULLDUPLEX, that appeared in the select code, and everything ran fine throughout the night. I will continue to monitor it.

In fact, I noticed that the functions called by the raw API ultimately originate from the thread-safe file socket.h mentioned on this webpage. So, it seems that to implement multithreading, I might need to enable some other macro definitions.

peter-h:
I can't help you directly but a couple of years ago I looked at implementing WIFI and ETH in my FreeRTOS+LWIP product and while I never did the WIFI part, some people said there are various problems with dual interfaces in LWIP.

Maybe they were doing similar stuff to you, but nobody posted solutions (which is normal; most people don't post what they finally did).

LWIP is complicated, with so many options with subtle effects. Take a look at some of my own LWIP threads. Also development of LWIP (a ~16 year old project) came to a standstill some years ago so there is little support from anywhere; people have moved on. It is a very solid product so I am happy to use it as it is.

You may want to implement a mutex for this, but I could not suggest at what level.

One guy who knows a lot about LWIP is dare.

Navigation

[0] Message Index

[#] Next page