TCP dissector - erroneous DSACK reporting
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]
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).