buglwIP - A Lightweight TCP/IP stack - Bugs: bug #31487, FIN_WAIT_1 timeout?

 
 

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

bug #31487: FIN_WAIT_1 timeout?

Submitted by:  Andrej <a_zupanc>
Submitted on:  Thu 28 Oct 2010 12:26:48 PM UTC  
 
Category: TCPSeverity: 3 - Normal
Item Group: Faulty BehaviourStatus: Works For Me
Privacy: PublicAssigned to: None
Open/Closed: ClosedPlanned Release: None
lwIP version: Other

Thu 28 Oct 2010 12:36:00 PM UTC, comment #1:

I think TCP keepalive would solve your problem. This will timeout a socket if no traffic is seen, and sends probes to check if the other end is still there if there is no application traffic.

However in FINWAIT1 we are waiting for the ACK of our FIN. I would expect the stack to retransmit the FIN until it reaches TCP_MAXRTX tries at which time the connection should be closed. This could take some time (up to hours) as TCP is very persistent at trying to recover in such situations. How long do you wait?

I'm closing this as I think there are two mechanisms that should achieve what you want. If one or the other isn't working please open a new bug to discuss that.

Kieran Mansley <kieranm>
Project Administrator
Thu 28 Oct 2010 12:26:48 PM UTC, original submission:

I face a situation in which TCP connection blocks in FIN_WAIT_1 state forever. In this case the embedded device running LWIP stack is acting as a server. The remote client initiates TCP communication to that embedded server. The IP communication runs over GPRS.
The problem appears when remote client "falls" off GPRS connection at the time when active TCP connection is running with the server. Of course when GPRS connection drops there is no possibility to exchenge FIN messages. So the TCP connection on embedded server remains opened not knowing anything about client being dropped from GPRS. To solve that situation we have a timeout implemented on application layer. After expiration of the application layer timeout, CLOSE is called on the opened connection, FIN message is sent from the server side, and the connection enters FIN_WAIT_1 state. However since the remote client is still down from GPRS it is unable to respond to that FIN message and here is where the problem arises. The connection on the server waits for the ACK message from the ether side which is never received, because there is nobody to answer it!!
My answer is if there should be a timeout implementation similar to that for FIN_WAIT_2 state timeout?

Andrej <a_zupanc>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by kieranm (Posted a comment)
  • -unavailable- added by a_zupanc (Submitted the item)
  •  

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 28 Oct 2010 12:36:00 PM UTCkieranmStatusNone=>Works For Me
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1