I'm working on a VDK based project that uses LWIP on a custom PCB with a BF537. The Blackfin board acts as a network server and sends a bunch of data over a TCP socket to the client when connected.
However, we've found that if the client does not read the data over the TCP socket but rather disconnects and reconnects repeatedly and quickly to the server that eventually the server seems to freeze. In this case, the BF537 has NOT gone into kernel panic, the USB-ICE reports that the target is still running, and I am unable to ping the server's IP.
If I halt the program via the USB-ICE, I can see that 3 threads were created for the LWIP ethernet stuff and that they are all blocking on a pending semaphore.
I've checked the server's code, it is not blocking on the send(). I think I'm correctly detecting the client disconnect and closing the socket on the server. At most, there should only be 2 simultaneous sockets open on the server. In the TCPIP Configuration Wizard the TCP Listen Backlog is set to 8, the number of TCP connections is set to 16 and the number of sockets is set to 32.
Does anyone have any ideas as to why this might happen or how to best debug this?
One thought I had is perhaps because I'm disconnecting and reconnecting so quickly, perhaps the maximum number of sockets or the TCP Listen Backlog is overrunning. The reason I'm considering this is perhaps the sockets have not been "cleaned up" fast enough if the ethernet driver is still trying to send data that has been put into the queue but had not been transmitted before the client disconnected. Is this somewhere I should be looking? If so, what are the best practices when trying to "clean up" sockets? Is there something other than close() that I should call to "clean up" the sockets better?
Thanks in advance.