Re: SACK oddity

Andy Ruhl <[email protected]>
Newsgroups gmane.os.netbsd.devel.network
Message-ID <CAJcb3fo+2BpOa27DJ+Bi3FC0Ar1=MoAf900J5uRxKXfR1OX2Sw@mail.gmail.com>
On Sun, Apr 14, 2024 at 7:24 AM Mouse <[email protected]> wrote:
>
> >> I'm seeing odd TCP behaviour with SACKs.  [...]
>
> >> The right edge of the SACK block equals the main TCP ACK sequence
> >> number, meaning it's SACKing data that's already ACKed normally.
> >> [...]
>
> > At first glance, this looks like D-SACK (RFC2883), but it's kinda
> > early in the morning, so perhaps I'm missing something?
>
> Ooh, thank you.  I was not previously aware of D-SACK.
>
> Yes, this looks a lot like D-SACK, possibly except for the timestamp
> indicating that it's a response to the first of the two copies of that
> data, as Greg Troxel pointed out.  But 2883 doesn't specify how D-SACK
> should interact with timestamps....
>
> So this might not be indicative of anything noteworthy.  Hmm.

Not sure if this is helping but it might. If you write the tcpdump to
a file or use tshark to get the trace, open it in Wireshark and go to
Analyze -> Expert Information.

It's not always useful but sometimes it can save a lot of time.

Andy
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.