Created attachment 2813 [details]
Patch for this bug.

I’ve found and strange behaviour during the TCP close procedure and I think that this may be a bug. In a nutshell, when the TCP socket is on the FIN_WAIT_2 state and receives a packet from peer with valid payload data and both the FIN and ACK flags, the ProcessWait () method was processing the packet data but was ignoring the FIN and ACK flags. Because of that, the state machine get stuck in the FIN_WAIT_2 state.

I’ve changed the first condition on TcpSocketBase::ProcessWait () from:

if (packet->GetSize () > 0 && tcpflags != TcpHeader::ACK)

to 

if (packet->GetSize () > 0 && !(tcpflags & TcpHeader::ACK)) 

and this seems to solve the problem. If I’m right, we only call the ReceivedData () directly if we don’t have the ACK flag to process, otherwise we need to call ReceivedAck () first (which will call ReceivedData later, if necessary). With the proposed change, the case of a packet with data and FIN + ACK will match the third condition, that will process the FIN flag.