This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Peculiar SACK behavior

0

Hi all,

I'm having a hard time wrapping my head around some peculiar traffic, and I'm hoping that the big brains here may be able to offer some insight.

In short ... this looks plain wrong:

42737 2014-12-02 17:06:04.822626 0.000004 2.057276000 0.001216000 10.10.10.10 20.20.20.20 118 27081 80 TCP 66 63960 63960 1921089026 1921091786 1306854153 4011022929 [TCP Dup ACK 42718#1] 27081→80 [ACK] Seq=1306854153 Ack=4011022929 Win=63960 Len=0 SLE=1921089026 SRE=1921091786

Src: 10.10.10.10 (third party ISP network) Dst: 20.20.20.20 (FE server)

Seq=1306854153 Ack=4011022929

SLE=1921089026 SRE=1921091786

I'm having a hard time wrapping my head around this behavior.

Could this be caused by a transit device (firewall/NAT) mucking about with the SACK option data?

Thanks, Kevin

asked 02 Dec '14, 10:10

Qwert's gravatar image

Qwert
16226
accept rate: 0%


2 Answers:

0

Thanks to another thread for putting me on the right track. This is looking like a /?/cosmetic/?/ anomaly due to TSO in use by the NIC. There seems to be a set value that the NIC/TCPstack/(wireshark) is applying to the SLE/SRE values on a per session basis.

answered 02 Dec '14, 15:00

Qwert's gravatar image

Qwert
16226
accept rate: 0%

0

Wow .. been a while since I've been on this site.

This had nothing to do with TSO, and in hindsight, I recognize that my assumption to that effect was based in ignorance.

This behavior was, indeed, due to a load balancing appliance operating in inline mode that was not supporting SACK rewrites.

live-and-learn

answered 24 Sep '15, 15:03

Qwert's gravatar image

Qwert
16226
accept rate: 0%

edited 24 Sep '15, 15:06