Ask Your Question

Window size drop to 11 with ACK packet

asked 2024-06-21 21:07:34 +0000

net_tech gravatar image

updated 2024-06-22 14:09:31 +0000

Chuckc gravatar image


What could cause a TCP Window size change during a handshake?

Linux Host is talking to a Windows Host. 6th column is tcp.time_delta_displayed (which seems to be too good to be true) Linux SYN packet does not have any TCP options which seems strange as well. Captured on the client side Windows

No. Source  Dest.       Proto   Len WinSize Time        Info
1   Linux   Windows     TCP     74  42340   0.000000000 52404 → 12800 [SYN] Seq=0 Win=42340

2   Windows  Linux      TCP     66  65535   0.000145000 12800 → 52404 [SYN, ACK] Seq=0 Ack=1 Win=65535 

3   Linux   Windows     TCP     60  11      0.000070000 52404 → 12800 [ACK] Seq=1 Ack=1 Win=11

Thank you

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2024-06-22 01:44:49 +0000

SYN-bit gravatar image

Too bad you were not around for the Packet Doctors session at Sharkfest for which you have submitted this capture, you would have had your answer already ;-)

The real (calculated) window size can't be 11, as much more data was sent. There is window scaling in place, so the 11 needs to be multiplied by a power of 2. The reason why there are not TCP options like MSS and WS is that all packets were sliced at 50 bytes, which cuts the TCP header in half (14 bytes ethernet, 20 bytes IP, so only 16 bytes of the 20-60 byte TCP header were captured).

edit flag offensive delete link more


Why would I also see Window=11 when Snaplen(B) is set to 500 ?

Taking a guess here... If am splitting my captures by 200MB each, Windows=11 is only visible in capture files that don't have access to the 3 way handshake ? Scaling factor of 4096 with a Window 11 makes the Window Size 45056

net_tech gravatar imagenet_tech ( 2024-06-22 15:21:00 +0000 )edit

Indeed not having the 3-way handshake has the same effect as too low snap length. That's why there's a dissector preference "Scaling factor to use when not available from capture".

Jaap gravatar imageJaap ( 2024-06-22 18:06:33 +0000 )edit

Got it! So going with snaplen of 61 should work in for any capture without loosing any header info?

net_tech gravatar imagenet_tech ( 2024-06-22 18:58:05 +0000 )edit

No, a snaplen of 61 is not necessarily sufficient for any capture. It might be enough, especially considering that the MSS is often the first option. Look at your own capture above, where the SYN packet is 74 bytes. As Sake said, the maximum length of a TCP header is 60 bytes, so to truly guarantee it over Ethernet/IPv4 would need 14 + 20 + 60 = 94 bytes.

And of course if you're capturing in an environment with IPv6, VLAN tags, MPLS labels, 802.1AE/MACsec, 802.1ah, other link-layers, etc., then other larger numbers may be necessary.

johnthacker gravatar imagejohnthacker ( 2024-06-23 01:25:25 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2024-06-21 21:07:34 +0000

Seen: 78 times

Last updated: Jun 22