Re: [lwip-users] TCP send() fails when other sockets perform retransmissions

[Daniel Pauli]

If you have LwIP stats enabled, you can check the memory pools for errors to figure out which one is failing.  You should be able to resolve this by sizing your memory pools to handle the number of supported connections.  For example if you only support 5 simultaneous TCP connections, then your pools should be big enough to allocate 5 send buffers worth of segments.  This is how I configure my products, which typically have plenty of RAM.  Not sure what the recommendation is for very constrained RAM products.

Using LwIP stats I found that memory allocations from RAW_PCB failed. By increasing MEM_SIZE I was able to avoid the issue. I'm still unsure about a reasonable value here, given that we want to support up to 64 simultaneous TCP connections (MEMP_NUM_TCP_PCB==64). It is not a constrained RAM product, though.

Yes there is, with SO_LINGER you can perform an abortive closure rather than graceful by setting the timeout to 0.  Typically this is a bad idea.  There’s a decent discussion here on stackoverflow:

http://stackoverflow.com/questions/3757289/tcp-option-so-linger-zero-when-its-required

 We are using the default setting of LWIP_SO_LINGER==0. If I understand correctly, this already completely disables linger processing and should correspond to an abortive closure by setting the timeout to 0 as you suggested. Is there another way to tell LWIP to release any resources associated with a socket immediately?

Even when increasing MEM_SIZE, I feel uneasy about misbehaving clients (ignoring retransmissions, reconnecting frequently) eating up all server resources over time. In the case of unanswered retransmissions, I observed that the TCP_PCB_LISTEN allocation counter is not decremented after close() for a long time (probably 25 minutes?).

Daniel