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.

Thanks for any insights!

Med

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 ***

Thanks! I confirmed that the sequence numbers reported in the SACK are
indeed relative to the ISN. I guess this points to a bug in the
server's TCP stack. That'll be fun trying to track down ;-)

Medgya

Barry Margolin wrote:
> 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.