What is happening when a TCP sequence number arrives that is not what is expected?

Question

I am writing a program that uses libpcap to capture packets and reassemble a TCP stream. My program simply monitors the traffic and so I have no control over the reception and transmittal of packets. My program disregards all non TCP/IP traffic.

I calculate the next expected sequence number from the ISN and then the successive SEQ numbers. I have it set up so that every TCP connection is uniquely identified by a tuple made up of the source IP, source port, dest IP, and dest port. Everything goes swimmingly until I receive a packet that has a sequence number different than what I am expecting. I have uploaded screen shots to help illustrate what I am describing here.

My questions are: 1. Where is the data that was in the "lost" packet? 2. How does the SEQ number order recover from this situation? 3. What can I do to handle these occurrences.

Please remember; however, I am not writing a program that adheres to TCP. I am writing a program that passively monitors network traffic for TCP streams and attempts to save the raw data to disk, and I am confused as to why the above state situation happens and how I can program to handle it.

Thank you

Answer 1

Where is the data that was in the "lost" packet?

• It got dropped by someone
• It got lost on the way (wrong detour) and will arrive later

How does the SEQ number order recover from this situation

The receiver notices the segment is out of sequence and doesn't send it to the application, thereby fulfilling its contract: in-order reliable byte stream. Now, what actually happens to get the missing piece is quite intricate and varies from stack to stack. In a nutshell the stack waits for the missing piece to arrive.

• The receiver can throw away out-of-sequence segments or it can queue them in a reassembly queue
• The receiver can wait for the missing segment to arrive or it can immediately send the ACK it already sent before. Duplicate ACKs will alert the peer something is wrong (look for Fast Retransmit)
• When sending acknowledgments the TCP can inform the peer some segments arrived successfully - they're just out of sequence (SACK)

What can I do to handle these occurrences

You can't do anything since you're only monitoring. You could probably get more insight into what is really happening if you also captured the response traffic.

Answer 2

Depending on the window-size of the current TCP connection, if the new packet fits within the receiving window (multi-packet buffer) it will be entered into the receiving queue (and reordered for ordered delivery to protocol clients).

If the sequence number is larger than the maximum for the current window, the packet gets rejected.

See also section 4.4.2 (INPUT PACKET HANDLER) in RFC 675