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

Submitted by:  Torbjørn Tvermosegaard <tbt>
Submitted on:  Mon 26 Jan 2015 01:56:10 PM UTC  
 
Category:  TCP Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Invalid
Privacy:  Public Assigned to:  Simon Goldschmidt <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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>

 

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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    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.5