[lwip-users] 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?