lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] [bug #19953] Bug in TCP State Machine - SYN_RCVD


From: Tom Hennen
Subject: [lwip-devel] [bug #19953] Bug in TCP State Machine - SYN_RCVD
Date: Thu, 24 May 2007 14:40:56 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

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

                 Summary: Bug in TCP State Machine - SYN_RCVD
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: thennen
            Submitted on: Thursday 05/24/2007 at 14:40
                Category: TCP
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

It is possible for a client to send a FIN+ACK to a server in the SYN_RCVD
state.  This will currently cause the server to get stuck in FIN_WAIT_2
(until it times out), when it should really transition to CLOSE_WAIT.

This can happen if a client closes a connection immediately after
receiving the SYN+ACK in the SYN_SENT state.  When this happens the client
may queue an 'ACK' for the 'SYN+ACK', but the ACK is delayed (waiting for
some data to go with it).  Then, before the ACK is sent, the client calls
'close'.  This causes the 'FIN' flag to be set and the packet to be sent to
the server.  Thus the server, sitting in the 'SYN_RCVD' state will receive a
packet with 'FIN+ACK' set.

As of lwIP 1.1.1 this will cause the state to be transitioned to
ESTABLISHED, the 'connected' callback will be called and then when
tcp_process calls tcp_receive. tcp_receive notices the 'FIN' flag and calls
the server's tcp_recv callback with a NULL pbuf.  The server, then calls
'tcp_close', which as the state is ESTABLISHED will cause the state to
transition to FIN_WAIT_1 *when in fact it should transition to CLOSE_WAIT*. 
Since the client is also in FIN_WAIT_1 another 'FIN' will not be sent and the
client will transition to TIME_WAIT, thus leaving server stuck in FIN_WAIT_2.

I figure the fix to this involves checking for the 'FIN' flag in the SYN_RCVD
state, after notifying the server via the 'connected' callback, transitioning
to the ESTABLISHED state and then transitioning to the CLOSE_WAIT state.




    _______________________________________________________

Reply to this item at:

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

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





reply via email to

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