Possible Bug in TCP State Machine

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible Bug in TCP State Machine

Tom Hennen
I've come across what is a possible bug in lwIPs TCP state machine.

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.  Another fix would involve
forcing clients to ACK the SYN+ACK immediately and not wait for data
as it does currently.

Thoughts?


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Possible Bug in TCP State Machine

Kieran Mansley
On Wed, 2007-05-23 at 13:15 -0400, Tom Hennen wrote:
> 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.

Agreed.  Thanks for an excellent report of the problem.  Could you file
a bug on savannah?

> Another fix would involve
> forcing clients to ACK the SYN+ACK immediately and not wait for data
> as it does currently.

We don't control all the other stacks that lwIP might talk to, so this
wouldn't be a very good fix as some are bound to have that behaviour.  

Kieran



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Possible Bug in TCP State Machine

Tom Hennen
Done - item #19953

On 5/24/07, Kieran Mansley <[hidden email]> wrote:

> On Wed, 2007-05-23 at 13:15 -0400, Tom Hennen wrote:
> > 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.
>
> Agreed.  Thanks for an excellent report of the problem.  Could you file
> a bug on savannah?
>
> > Another fix would involve
> > forcing clients to ACK the SYN+ACK immediately and not wait for data
> > as it does currently.
>
> We don't control all the other stacks that lwIP might talk to, so this
> wouldn't be a very good fix as some are bound to have that behaviour.
>
> Kieran
>
>
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users