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