Re: [lwip-users] lwip stall

[Kieran Mansley]

On Wed, 2009-06-17 at 17:53 +0200, PELISSIER Christophe wrote:
> In case those buffers are inside the lwip stack waiting for
> acknowledgement, i guess a timer mechanism should be implemented to
> free the buffer if no acknowledgement is received. am i right? what is
> the process for this buffer release mechanism? what is the maximum
> time the packet will stays "in use" in that case? 

If no acknowledgement is received (and we're talking about TCP rather
than UDP or something else, you didn't say which) lwIP will try to
retransmit the packets.  It does this repeatedly, first time takes a few
hundred milliseconds, but subsequent attempts back off the time between
retransmissions.  If after a number of (I don't recall exactly how many)
attempts at retransmitting it still hasn't had an acknowledgement it
will close the connection and the buffers will be freed, but this whole
process can take a very long time, certainly many minutes, as TCP is
very conservative about closing connections.

If you have a debugger, have a look at the tcp_active_pcbs list, and for
each pcb in that list, look at "unsent", "unacked" and "ooseg".  These
are all lists of TCP segments that each connection has.

I would guess from your description that you're getting a lot of packets
in the ooseg list.  I don't remember off the top of my head if there
were bugs between 1.2 and 1.3 concerning the queueing of out of order
segments, but it wouldn't surprise me.  You could, if you wanted,
disable TCP_QUEUE_OOSEG and see if that helps.

Kieran