Re: [lwip-users] Issue with "blocked" pcbs

[Klaus Breining]

Hello,

about the issue below, I found out something new:
I have seen the following sequence:
- Receive SYN
- Answer SYN/ACK
- Receive ACK
Up to now everything is normal. Here altcp_tcp_accept() is called.
PCB is ESTABLISHED
- Receive PSH/ACK
- Answer PSH/ACK
- Receive ACK
- Send FIN/PSH/ACK
- Receive RES/ACK
Reset processing ends up in tcp_ack_now(), the flag acceptable is not 
set. The function tcp_process() returns ERR_OK without doing anything 
with the PCB.

How this PCB will ever disappear? It is now in state FIN_WAIT_1 with 
flags TF_RXCLOSED | TF_FIN. The PCB will never receive anything again 
and the slow timer tcp_slowtmr() is the only function that could change 
the state of a PCB - but it only resends the last FIN/PSH/ACK package 
every few seconds to a port which obviously the browser on the other 
side has already closed.

This function should also check the FIN_WAIT_1 state and set pcb_remove 
after no state-change for a long time.

Is this a bug or is there anything I didn't see?

Regards
Klaus


Am 27.12.2020 um 19:18 schrieb 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
>
>
> _______________________________________________
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users