In article <1142505148.485385.144100@i40g2000cwc.googlegroups .com>,
"Medgya" <medgyadal@yahoo.com> wrote:

> Hello,
>
> Except perhaps in cases of sequenc number wrap-around, is it ever
> legitimate for the ACK value in a TCP segment to be greater than the
> left edge of the leftmost block in the accompanying SACK options? I'm
> seeing packets like this coming back from an FTP server X.X.X.X (the
> remote client Y.Y.Y.Y is doing an active-mode STOR, but I don't show
> those packets here):
>
> 11:09:11.162335 IP (tos 0x0, ttl 64, id 2075, offset 0, flags [DF],
> length: 72) X.X.X.X.20 > Y.Y.Y.Y.2565: . [tcp sum ok] 1:1(0) ack 99543
> win 10912 <nop,nop,timestamp 924970291 6793494,nop,nop,sack sack 2
> {96739:98129}{100945:119171} >
>
> 11:09:11.175782 IP (tos 0x0, ttl 64, id 2081, offset 0, flags [DF],
> length: 64) X.X.X.X.20 > Y.Y.Y.Y.2565: . [tcp sum ok] 1:1(0) ack 119171
> win 11596 <nop,nop,timestamp 924970294 6793494,nop,nop,sack sack 1
> {100945:102335} >
>
> My understanding was that the ACK value always represents just what it
> does without SACK -- the right edge of contiguous received data, so in
> that interpretation the ACK values above don't seem to make sense.

I agree.

One thing to check -- are both the ACK and SACK values relative to the
ISN? I think either tcpdump or Ethereal has a bug where SACKs are
displayed as absolute values even when displaying relative sequence
numbers and ACKs.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***