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

[Jan Ulvesten]

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="">>

 

 

Jan Ulvesten

SICOM

 

 

 

 

 

lwip connection stuck in Closing state - filtered
Description: lwip connection stuck in Closing state - filtered