Created attachment 981 [details]
Test case for suspected bug in TcpSocketImpl's handling of data attached to a FIN packet received while in the FIN-WAIT-2 state.

TcpSocketImpl loses data attached to a FIN packet received while in the FIN-WAIT-2 state. 

Attached: Test case for suspected bug in TcpSocketImpl's handling of data attached to a FIN packet received while in the FIN-WAIT-2 state.

Demonstrated here using two nodes which approximately enact the following sequence of events:

1. Acceptor node opens socket listening for connections
2. Initiator node connects to acceptor.
3. Initiator node has nothing to send, calls Socket::Close()
4. Acceptor node queues five 100-byte packets.
5. Acceptor node calls Socket::Close()
6. Acceptor's TcpSocketImpl sends the 5 packets, the last one of which contains both data and the FIN flag.
7. Initiator node's TcpSocketImpl receives the first four packets and forwards them to the application's Receive callback properly.
8. Initiator node's TcpSocketImpl (which is in FIN-WAIT-2 state) receives the last packet with 100 bytes of data and a FIN flag. This fully closes the connection, but the data never makes it to the application; the receive callback is called with a NULL packet.

The problem in TcpSocketImpl:

ForwardUp(), which handles the packet, calls ProcessEvent() before it calls ProcessPacketAction(). 

ProcessEvent() sees that we're in FIN-WAIT-2, sees an incoming FIN (doesn't care that it has data attached to it), and therefore goes to the CLOSE-WAIT state and calls NotifyDataRecv(), which calls the application's RecvCallback with a NULL packet because there is nothing in m_pendingData. 

m_pendingData WOULD have been filled by ProcessPacketAction()... but that hasn't been called yet.

The corresponding code in ns-2's full TCP doesn't have this problem - events occur in an order which allows the data to make it to the application.

Note that the problem doesn't occur when the time between sends is 100 ms or greater.