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:  TCP Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Works For Me
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Planned 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 Member
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
  • -email is unavailable- added by kieranm (Posted a comment)
  • -email is unavailable- added by a_zupanc (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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-10-28 kieranm StatusNone => Works For Me
        Open/ClosedOpen => Closed

    Back to the top


    Powered by Savane 3.5