TCP ACKed unseen segment

Question

Why do wireshark say "TCP ACKed unseen segment" in frame 718 (see below) when the segment has been seen in frame 713 ??

No.     Time            Source                Destination           Protocol Length Info                                                            
    712 14:18:42.604065 10.11.78.193          10.168.1.11           TLSv1    1434   Ignored Unknown Record
Frame 712: 1434 bytes on wire (11472 bits), 1434 bytes captured (11472 bits)
Ethernet II, Src: Cisco_ff:fc:f0 (00:08:e3:ff:fc:f0), Dst: Hewlett-_77:98:28 (18:a9:05:77:98:28)
Internet Protocol Version 4, Src: 10.11.78.193 (10.11.78.193), Dst: 10.168.1.11 (10.168.1.11)
Transmission Control Protocol, Src Port: https (443), Dst Port: 39083 (39083), Seq: 494642, Ack: 1, Len: 1380
Source port: https (443)
Destination port: 39083 (39083)
[Stream index: 4]
Sequence number: 494642    (relative sequence number)
[Next sequence number: 496022    (relative sequence number)]
Acknowledgment number: 1    (relative ack number)
Header length: 20 bytes
Flags: 0x010 (ACK)
Window size value: 63531
[Calculated window size: 63531]
[Window size scaling factor: -1 (unkown)]
Checksum: 0x31d7 [validation disabled]
No.     Time            Source                Destination           Protocol Length Info                                                         

713 14:18:42.604067 10.11.78.193          10.168.1.11           TLSv1    1434   Ignored Unknown Record
Frame 713: 1434 bytes on wire (11472 bits), 1434 bytes captured (11472 bits)
Ethernet II, Src: Cisco_ff:fc:f0 (00:08:e3:ff:fc:f0), Dst: Hewlett-_77:98:28 (18:a9:05:77:98:28)
Internet Protocol Version 4, Src: 10.11.78.193 (10.11.78.193), Dst: 10.168.1.11 (10.168.1.11)
Transmission Control Protocol, Src Port: https (443), Dst Port: 39083 (39083), Seq: 496022, Ack: 1, Len: 1380
Source port: https (443)
Destination port: 39083 (39083)
[Stream index: 4]
Sequence number: 496022    (relative sequence number)
[Next sequence number: 497402    (relative sequence number)]
Acknowledgment number: 1    (relative ack number)
Header length: 20 bytes
Flags: 0x010 (ACK)
Window size value: 63531
[Calculated window size: 63531]
[Window size scaling factor: -1 (unkown)]
Checksum: 0xbb9a [validation disabled]
No.     Time            Source                Destination           Protocol Length Info                                                         

718 14:18:42.604093 10.168.1.11           10.11.78.193          TCP      60     [TCP ACKed unseen segment] 39083 > https [ACK] Seq=1 Ack=496022
Frame 718: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: Hewlett-_77:98:28 (18:a9:05:77:98:28), Dst: Cisco_ff:fc:f0 (00:08:e3:ff:fc:f0)
Internet Protocol Version 4, Src: 10.168.1.11 (10.168.1.11), Dst: 10.11.78.193 (10.11.78.193)
Transmission Control Protocol, Src Port: 39083 (39083), Dst Port: https (443), Seq: 1, Ack: 496022, Len: 0
Source port: 39083 (39083)
Destination port: https (443)
[Stream index: 4]
Sequence number: 1    (relative sequence number)
Acknowledgment number: 496022    (relative ack number)
Header length: 20 bytes
Flags: 0x010 (ACK)
Window size value: 64170
[Calculated window size: 64170]
[Window size scaling factor: -1 (unkown)]
Checksum: 0x6d38 [validation disabled]
[SEQ/ACK analysis]

Answer 1

First, the ACK from one system is the next expected sequence number from the other system, not a sequence number that has already been seen. The ACK of 496022 in frame 718 is not acknowledging the sequence number of 496022 in frame 713; its saying that the sequence number 496022 is what it expects next. The ACK in frame 718 is acknowledging frame 712, not frame 713. The sequence number of frame 712 is 494642 and there 1380 bytes in the TCP portion of that frame, so frame 712 contains bytes 494642 through 496021, and 496022 should be next. You can see "Next sequence number: 496022" in the Packet Details portion of Frame 712.

Second, ACKs are cumulative. When 10.68.1.11 sends an ACK of 496022, it's not only saying that it expects sequence number 496022 next, it's also saying that it has received bytes 1 through 496021. So, by transmitting a sequence number of 496022,10.68.1.11 is saying that it has received all data from 10.11.78.193 up through and including frame 712. Somewhere before frame 712 there was a frame that Wireshark didn't see.

Answer 2

0

Could a segment from 10.11.78.193 be missing before frame 712? What was the last ACK number from 10.168.1.11 before frame 712 and what were the frames of 10.11.78.193 since the previous ACK of 10.168.1.11?

Could you upload the capture file to www.cloudshark.org and ost the link here for us to check?

answered 21 Dec '12, 06:59

SYN-bit ♦♦
17.1k●9●57●245
accept rate: 20%

I am sorry but capture wasn´t saved, but why should a missing segment before frame 712 have any influence on the dialog from 713 and onwards ?

(22 Dec '12, 15:28) gschaarup

Consider this:

a->b seq 100, len 10, ack 1
a->b seq 120, len 10, ack 1
a->b seq 130, len 10, ack 1
b->a seq 1, ack 140

clearly b is acking a segment (seq 110-119) that has not been seen by wireshark.

(22 Dec '12, 15:35) SYN-bit ♦♦

But:

frame 713 10.11.78.193 -> 10.168.1.11 is seq 496022
frame 718 10.168.1.11 -> 10.11.78.193 is ack 496022

and here wireshark say "TCP ACKed unseen segment" (why unseen, when the packet (seq=496022) has been seen in frame 713 ?)

(01 Jan '13, 22:22) gschaarup

Wireshark might indeed be wrong here. But I tried to say that that depends on the packets before frame 712. Are you able to share the pcap file of the whole TCP stream?

You could upload it to www.cloudshark.org and paste the link to it in a comment.

(02 Jan '13, 00:49) SYN-bit ♦♦