TCP dissector - erroneous DSACK reporting
Summary
Erronous reports of DSACK blocks by TCP dissector
Steps to reproduce
Capture shows a few Duplicate ACKs with valid SACK blocks. DSACK block is reported and tcp.options.sack.dsack is set
What is the current bug behavior?
Wireshark 3.4.4 reports DSACK blocks (the first SACK block in a TCP SACK option, with the left & right edge being lower than or equal to the ACK field) erraneously, for regular SACK blocks (see below)
What is the expected correct behavior?
A DSACK block is defined as the first SACK block where the left edge is below ACK, and the right edge is lower than or equal to ACK.
In the above example, ACK is 2766491107. The first SACK block is 2766543235-2766560611, but 2766543235 > 2766491107, and 2766560611 > 2766491107, thus this is a regular SACK block, and NOT a DSACK block.
Note that an invalid SACK instance also exists, when the left edge of a SACK block is lower than ACK, and the right edge is larger than ACK. This may warrant a separate error (it is a critical error), since this should never happen. The only instances where such an invalid SACK block may be seen would be a) a TCP stack with a buggy SACK implementation, or b) a middlebox modifying the sequence numbers in the header, but not bothering (or incorrectly dealing) with SACK sequence numbers.
Sample capture file
Relevant logs and/or screenshots
Frame 164710: 102 bytes on wire (816 bits), 102 bytes captured (816 bits)
Ethernet II, Src: Cisco_1d:34:40 (30:f7:0d:1d:34:40), Dst: Cisco_34:e8:00 (00:24:c3:34:e8:00)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 810
Internet Protocol Version 4, Src: 10.160.194.12, Dst: 10.168.76.22
Transmission Control Protocol, Src Port: 11105, Dst Port: 55095, Seq: 679308515, Ack: 2766491107, Len: 0
Source Port: 11105
Destination Port: 55095
[Stream index: 0]
[TCP Segment Len: 0]
Sequence Number: 679308515
[Next Sequence Number: 679308515]
Acknowledgment Number: 2766491107
1111 .... = Header Length: 60 bytes (15)
Flags: 0x010 (ACK)
Window: 2625
[Calculated window size: 672000]
[Window size scaling factor: 256 (missing - taken from preference)]
Checksum: 0x649e [unverified]
[Checksum Status: Unverified]
Urgent Pointer: 0
Options: (40 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps, No-Operation (NOP), No-Operation (NOP), SACK
TCP Option - No-Operation (NOP)
TCP Option - No-Operation (NOP)
TCP Option - Timestamps: TSval 1471382728, TSecr 3369077276
TCP Option - No-Operation (NOP)
TCP Option - No-Operation (NOP)
TCP Option - SACK 2766543235-2766560611 2766521515-2766538891 2766492555-2766520067
Kind: SACK (5)
Length: 26
left edge = 2766543235
right edge = 2766560611
left edge = 2766521515
right edge = 2766538891
left edge = 2766492555
right edge = 2766520067
[TCP SACK Count: 3]
[D-SACK Left Edge = 2766543235]
[D-SACK Right Edge = 2766560611]
D-SACK Sequence
[Expert Info (Warning/Sequence): D-SACK Sequence]
[D-SACK Sequence]
[Severity level: Warning]
[Group: Sequence]
[SEQ/ACK analysis]
[Timestamps]
Build information
3.4.4 (v3.4.4-0-gc33f6306cbb2)
Compiled (64-bit) with Qt 5.15.1, with libpcap, with GLib 2.52.3, with zlib
1.2.11, with SMI 0.4.8, with c-ares 1.15.0, with Lua 5.2.4, with GnuTLS 3.6.3
and PKCS #11 support, with Gcrypt 1.8.3, with MIT Kerberos, with MaxMind DB
resolver, with nghttp2 1.39.2, with brotli, with LZ4, with Zstandard, with
Snappy, with libxml2 2.9.9, with QtMultimedia, with automatic updates using
WinSparkle 0.5.7, with AirPcap, with SpeexDSP (using bundled resampler), with
Minizip.
Running on 64-bit Windows 10 (2009), build 19042, with Intel(R) Core(TM)
i5-7300U CPU @ 2.60GHz (with SSE4.2), with 24410 MB of physical memory, with
locale German_Austria.utf8, with light display mode, without HiDPI, with Npcap
version 1.10, based on libpcap version 1.9.1, with GnuTLS 3.6.3, with Gcrypt
1.8.3, with brotli 1.0.2, without AirPcap, binary plugins supported (21 loaded).
Built using Microsoft Visual Studio 2019 (VC++ 14.28, build 29910).