Comment # 1
on bug 11624
from Christopher Maynard
(In reply to tferguson from comment #0)
> Please see the attached capture. Packets 39-46 are ACKing for packet 47.
> Shouldn't this be normal behavior to ack for the next expected packet with
> data?
Frames 39-46 are ACK's for all bytes sent up to the (ACK number - 1), and not
really an ACK for Frame 47.
Anyway, yes, the ACK's are normal; however, look at Frame 36. The last ACK was
for 10088 (using relative sequence numbering), meaning the 10.10.166.201 host
expects 10088 as the next sequence number, which is seen in the 2 ACK's coming
from 10.20.119.32 in Frames 37 and 38, but with no data. So what happened to
the 1368 bytes (11456-10088) transferred from 10.20.119.32 to 10.10.166.201
between Frames 38 and 39? There must have been some data transferred that
wasn't captured; otherwise 10.10.166.201 would still be ACK'ing 10088, not
11456.
> Look at packets 69-76. 69-74 are ACKing for packet 76, but these are
> not flagged as "TCP ACKed unseen segment".
Again, frames 69-74 are not ACK's for a future packet in frame 75, but rather
they are ACK's for all bytes transferred up to the (ACK number - 1). It can be
thought of as the next expected sequence number but it's definitely
acknowledging the reception of past data, not future data. So why are these
not flagged as "TCP ACKed unseen segment"? The prior ACK before Frame 69 from
10.10.166.201 is seen in Frame 64 and its value is 12725 (again, relative). It
can be seen that that is indeed the sequence number from 10.20.119.32 in Frames
65-76, which are just ACK's and carry no data, and again in Frame 68 which
carries 277 bytes of TCP payload. If you add 12725 + 277, you get 13002, which
is the ACK number in frames 69-74, just as you would expect if 10.10.166.201
received the 277 byte TCP payload packet of Frame 68.
You are receiving this mail because:
- You are watching all bug changes.