Re: [lwip-users] PCB Stuck in CLOSING state. Ack is not accepted?

[Bill Knight]

I have come across this problem with other stacks.  The fix I have
seen most often is to add a timeout.

Regards
-Bill Knight
R O SoftWare


On Mon, 12 Dec 2005 14:39:05 +0100, Jan Ulvesten wrote:

>Hi
> 
>I have earlier reported that some TCP connections gets stucked in the
>state CLOSING. 
> 
>According to the RFC793, the CLOSING state is a state where both ends
>have sent a FIN, but the ACK on the FIN has not yet been received. There
>is not timeout in the CLOSING state. I guess that the CLOSING state
>isn't used to often.
> 
>I have now analyzed this somewhat further.
> 
>tcp_in.c :
>...
>  case FIN_WAIT_1:
>    tcp_receive(pcb);
>    if (flags & TCP_FIN) {
>      if (flags & TCP_ACK && ackno == pcb->snd_nxt) {
>               ....
>      } else {
>          tcp_ack_now(pcb);                    <-- control goes here
>every time in my test setup.
>          pcb->state = CLOSING;
>      }
>...
>            
> 
>In my test setup: Every time a FIN is received in FIN_WAIT_1 state,
>control goes to the part where the state is set to CLOSING
>The received flags are TCP_FIN and TCP_ACK.  ackno is equal to
>pcb->snd_nxt+1 ??
> 
>ackno is equal to pcb->snd_nxt+1 ->  Is this really correct ? Should it
>be if (flags & TCP_ACK && ackno >= pcb->snd_nxt) ?
> 
>Attached in an Ethereal example. I currently recover by tcp_rst () if
>remaining in CLOSING state for 10 secs.
> 
>In packet #22, lwIP transmits FIN with seq. no 11525. 
>In packet #26 my PC transmits FIN with ACK to 11526.   It should really
>do?
> 
>For info: I test my opening a web page with a refresh timer of 3
>seconds. This produces HTTP traffic continuously. 
><meta http-equiv="refresh" content="3, URL=/ethernet_stat.htm">
> 
> 
>Jan Ulvesten
>SICOM
> 
> 
> 
> 
>