[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #26062] FIN_WAIT_2 state following tcp_close should ti

From: Jeff Barber
Subject: [lwip-devel] [bug #26062] FIN_WAIT_2 state following tcp_close should timeout eventually
Date: Wed, 01 Apr 2009 13:16:20 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2009032609 Firefox/3.0.8


                 Summary: FIN_WAIT_2 state following tcp_close should timeout
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: jeffbabar
            Submitted on: Wed 01 Apr 2009 01:16:18 PM GMT
                Category: TCP
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: CVS Head



If an application calls tcp_close, this indicates that it no longer needs the
connection (i.e. it's equivalent to closing the socket descriptor in Unix). 
Hence, after a FIN is sent to the peer, the TCP session should enter a state
where it is guaranteed to be destroyed eventually.  In the typical TCP
implementation (see reference below), this is achieved by an additional
FIN_WAIT_2 timer.  There is no such mechanism in the current lwIP
implementation -- the session and associated data structure may hang around
forever if the remote peer doesn't send a FIN of its own.

>From "TCP/IP Illustrated Volume 2", chapter 25, section 25.1, bullet 6
"A FIN_WAIT_2 timer. When a connection moves from the FIN_WAIT_1 state to the
FIN_WAIT_2 state (Figure 24.15) and the connection cannot receive any more
data (implying the process called close, instead of taking advantage of TCP's
half-close with shutdown), this timer is set to 10 minutes. When this timer
expires it is reset to 75 seconds, and when it expires the second time the
connection is dropped. The purpose of this timer is to avoid leaving a
connection in the FIN_WAIT_2 state forever, if the other end never sends a
FIN. (We don't show this timeout in Figure 24.15.)"


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]