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 [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
