lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] [bug #31487] FIN_WAIT_1 timeout?


From: Andrej
Subject: [lwip-devel] [bug #31487] FIN_WAIT_1 timeout?
Date: Thu, 28 Oct 2010 12:26:49 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sl; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11

URL:
  <http://savannah.nongnu.org/bugs/?31487>

                 Summary: FIN_WAIT_1 timeout?
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: a_zupanc
            Submitted on: Thu Oct 28 12:26:48 2010
                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: Other

    _______________________________________________________

Details:

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?




    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?31487>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/




reply via email to

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