I found an interesting bug in the behavior of FreeRTOS_select() that when used on a listening socket it would not fire when a client connected but only after an additional paket got received. I found a forum entry of someone who seemed to have the same issue but it didn't help me initially:
FreeRTOS Support Archive
Trying to debug the issue myself I found out that contrary to what was happening to the fellow in the forum post, with my version of FreeRTOS+TCP (2.0.1) I needed to switch ipconfigTCP_HANG_PROTECTION on to make select() behave correctly.
The problem seems to be in FreeRTOS_TCP_IP.c:1449
This code path leads eventually to
xParent->xEventBits |= ( eSELECT_READ << SOCKET_EVENT_BIT_COUNT );
which I think triggers the select() event.
However, pxSocket->u.xTCP.bits.bPassQueued is only set to true if
a) socket reuse is enabled (line 3125)
b) hang protection is enabled (line 3245)
Since I'm using multiple listening sockets, of which each can have multiple clients connected to it a) isn't usable for me. I'm using b) for now.
It seems to me, though, that hang protection shouldn't be required for select() to be triggered on an incoming connection.
