Window size drop to 11 with ACK packet

tcp.window

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

net_tech
120 ●35 ●40 ●51

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

Chuckc
3023 ●6 ●608 ●20

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

add a comment

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

SYN-bit

18528 ●9 ●339 ●255 https://SYN-b.it

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

Comments

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 ( 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 ( 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 ( 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 ( 2024-06-23 01:25:25 +0000 )edit

add a comment

Window size drop to 11 with ACK packet

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Window size drop to 11 with ACK packet edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Window size drop to 11 with ACK packet