buglwIP - A Lightweight TCP/IP stack - Bugs: bug #44092, tcp_pcb hangs in FIN_WAIT_1 after...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #44092: tcp_pcb hangs in FIN_WAIT_1 after lwip_close call

Submitter:  Torbjørn Tvermosegaard <tbt>
Submitted:  Mon 26 Jan 2015 01:56:10 PM UTC
   
 
Category:  TCP Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Invalid
Privacy:  Public Assigned to:  goldsimon
Open/Closed:  Closed Planned Release:  None
lwIP version:  1.4.0

Jump to the original submission

Thu 31 Aug 2017 01:42:54 PM UTC, comment #9: 

Sure. Thank you for the pointer.

Navaneeth Y V <navaneethyv>
Thu 31 Aug 2017 05:11:04 AM UTC, comment #8: 


> This is a pretty long interval actually.


Yes, it is. But it's like that throughout the whole connection lifetime. If that's too long for your application, you can always enable tcp keepalive.

Simon Goldschmidt <goldsimon>
Group administrator
Thu 31 Aug 2017 05:09:04 AM UTC, comment #7: 

Hi Simon,

Thank you for pointing me to bug #31487. When I was going through the code I some how had missed the part that TCP PCB moved to FIN_WAIT_1 will still be in tcp active list. But answer given by Kieran helped me find the missing piece. PCB will still be in the Active list. When the code for slow timer kicks in we go through the active list and try to resend unacked segments. During this  the RTO increases significantly over time (with each retransmissions) and with expiry of every RTO we make a note of it by incrementing nrtx, (Number of retransmissions I think).  When it hits TCP_MAXRTX (12) the PCB finally gets freed. This is a pretty long interval actually. Hence I mistook it for being stuck.

Thank you for the help again.

Navaneeth Y V <navaneethyv>
Wed 30 Aug 2017 05:52:56 AM UTC, comment #6: 

Or alternatively, search google. This is a common TCP problem, not lwIP related.

Simon Goldschmidt <goldsimon>
Group administrator
Wed 30 Aug 2017 05:48:04 AM UTC, comment #5: 

Actually, this is an exact duplicate to bug #31487 from 2010. Read Kieran's answer there why FIN_WAIT_1 is different to FIN_WAIT_2.

Simon Goldschmidt <goldsimon>
Group administrator
Wed 30 Aug 2017 05:32:03 AM UTC, comment #4: 

Sorry to Revive this old bug, I could hit a similar issue today. Essentially the application of lwip initiates a close connection because of which TCP gets into FIN_WAIT_1. Now because of a policy if we are dropping the packets from the other peer ( That is no accept ACK / FIN ) We will be stuck in this state.

From the code I can see that if we are in FIN_WAIT_2 we run a timer to clear it up.

    if (pcb->state == FIN_WAIT_2) {
      /* If this PCB is in FIN_WAIT_2 because of SHUT_WR don't let it time out. */
      if (pcb->flags & TF_RXCLOSED) {
        /* PCB was fully closed (either through close() or SHUT_RDWR):
           normal FIN-WAIT timeout handling. */
        if ((u32_t)(tcp_ticks - pcb->tmr) >
            TCP_FIN_WAIT_TIMEOUT / TCP_SLOW_INTERVAL) {
          ++pcb_remove;
          LWIP_DEBUGF(TCP_DEBUG, ("tcp_slowtmr: removing pcb stuck in FIN-WAIT-2\n"));
        }
      }
    }


But what about the cases in which we are in FIN_WAIT_1 ? Please let me know if I have missed out something.

Thank you!

Navaneeth Y V <navaneethyv>
Fri 01 Jul 2016 01:33:33 AM UTC, comment #3: 

Sorry to post to an old bug, however I also ran into this today. I waited 5 minutes for the PCB to be cleaned up by timeouts to no avail. I noticed that once the PCB is in the FIN_WAIT_1 state and has had tcp_close called on it, there is no transition out of this state in the tcp_slowtmr task. However there is a transition for FIN_WAIT_2. Is it possible this was mistaken as the timeout?

Ben Kneale <benkneale>
Sat 21 Mar 2015 09:11:45 PM UTC, comment #2: 

There is a timeout, it's just much longer than you expect. TCP is very conservative in timeouts and this is the standard TCP timeout, so if you need a faster timeout, you're correct in implementing your own timeout mechanism in the application layer.

Simon Goldschmidt <goldsimon>
Group administrator
Tue 27 Jan 2015 07:33:22 PM UTC, comment #1: 

Yes, there should be a timeout on close in this case, I guess.

Simon Goldschmidt <goldsimon>
Group administrator
Mon 26 Jan 2015 01:56:10 PM UTC, original submission:  

On a socket connection to a PC through a switch it seems that the lwip does not properly handle the situation, that the cable between switch and PC is disconnected (this means that interface in lwip is still up). I have an application that discovers the lack of communication and calls lwip_close, but it seems that the tcp_pcb is stuck in FIN_WAIT_1 because it never receives any further data on the connection.

Torbjørn Tvermosegaard <tbt>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by navaneethyv (Posted a comment)
  • -email is unavailable- added by benkneale (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by tbt (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-03-21 goldsimon StatusNone Invalid
        Assigned toNone goldsimon
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code