[lwip-users] Issue with "blocked" pcbs

[Klaus Breining]

Hello,

I am using a (modified) version of the http-server in the apps directory 
using application layer tcp (altcp_*). Before I was directly using the 
tcp callback api, but to use mbedtls, I have changed the tcp-calls to 
altcp-calls and compared the logic line-by-line with the sample code to 
check, if the sequence of calls is identical.

Using tcp-calls I never had issues. Even under heavy load there are no 
memory leaks and all tcp_pcbs are freed after some time even when I 
brutally kill connections in different ways.

Using altcp-calls, after some time (sometimes hours, sometimes I can 
create the situation after minutes) all tcp_pcbs are blocked. To get 
fast into the situation, I have set

#define MEMP_NUM_TCP_PCB   4

#define MEMP_NUM_ALTCP_PCB    11

This is the situation after some time: (Flag C => TF_RXCLOSED, Flag 
F=>TF_FIN)

-------- PCB list --------
  active 0x2000ca1c: 192.168.10.23:80 (CF 4 5)
  active 0x2000cacc: 192.168.10.23:80 (CF 4 5)
  active 0x2000cb7c: 192.168.10.23:80 (CF 4 5)
  active 0x2000c96c: 192.168.10.23:80 (CF 4 5)
  listen 0x2000dbf8: 0.0.0.0:80
  listen 0x2000dbd8: 0.0.0.0:443
--------------------------
The numbers in brackets are the last max. 16 states of the pcb, here 
ESTABLISHED -> FIN_WAIT_1

Now all tcp_pcbs are hanging in FIN_WAIT_1. This state is not handled in 
tcp_slowtmr(). The only function which handles this state is 
tcp_process(), but obviously there are situations in which either 
tcp_process() for this pcb_state is never called or in which in the 
state-handler is doing nothing (which means, that neither TF_GOT_FIN nor 
TCP_ACK are set).

I assume that this is not an issue of the altcp-API but a timing issue. 
I am using a quite slow CPU (Texas Instruments Tiva TM4C129 with quite 
small RAM (256kByte) for TLS-usage.

Does anyone have an idea, how the system gets into this state (and more 
important, how to get out of it :) )?

Regards

Klaus