ACKed lost segments - false positive?

Question

Hi,

not sure if I am too dumb to get that right, but I am puzzled by that finding:

In a 30-sec trace I found quite a few packet pairs, each one for another socket/stream (and the only packets for those sockets(/streams during the captured period at all) like that one:

Time                       Source                Destination           Protocol Info
407 2011-12-14 17:17:30.182151 172.17.55.50          172.17.55.73          TCP      48730 > 33779 [ACK] Seq=1 Ack=1 Win=294 Len=0 TSV=3645344977 TSER=2526914065
408 2011-12-14 17:17:30.182199 172.17.55.73          172.17.55.50          TCP      [TCP ACKed lost segment] 33779 > 48730 [ACK] Seq=1 Ack=2 Win=63 Len=0 TSV=2526974281 TSER=3645284761

This is not quite clear to me: packet 407 comes with a sequence number of 1. In 408, the reply means: got all data up to seq 1, expect at least seq 2 ... Can't see why that is not a perfect ACK to the preceeding packet.

Another question is of course where that SeqNumber 1 comes from. Would not carry the SYN-ACK and the following ACK during session establishment already seq number 1? So - as the socket was established before the capture apparently, the only explanation would be a wraparound of the seq number. But: for all the seen suspicious ACK pairs where Wireshark sees ACKs for lost segments, the seq.nums and ACKs have the same values (1, 2) ! If however the initial SeqNumber is 0, the numbers in those packets would be ok, but then Wireshark should flag the first of the packets as ACKed lost segment (as the preceeding one in that stream is indeed not captured !), shouldn't it?

Any advice welcome.

Uwe

Answer 1

Lets first start with the value of the SEQ and ACK. By default Wireshark will show relative sequence numbers. This means, it takes the sequence number of the SYN and SYN/ACK packets as reference and calculates the difference. The result is shown. You can verify this by clicking on the SEQ or ACK field and look at the 4 bytes in the hex pane, they show a different number. If Wireshark did not see the SYN, the SEQ and ACK of the first packet of the conversation will be shown as 1.

Now for the "ACK lost segment", the SEQ in frame 407 is 1, but its tcp length is 0, so the next expected sequence number would again be 1. So when the ACK in frame 408 comes with a value of 2, there must have been (at least) one frame lost. This can also be seen by looking at the TCP Timestamp options. The TSER in frame frame 408 is the "echo" of the last seen TSV from the other side. As the TSV in frame 407 is smaller than the TSER in frame 408, this means there must have been at least one other packet on the network in between those packets.

Then for the grande finale, since these two frames come right after one-another in the tracefile, the only logical conclusion would be that the capture process was not able to capture all packets to disk during the capturing.