Wireshark not showing all "TCP window full"?

asked 2018-05-04 10:43:48 +0000

airshark
3 ●2 ●2 ●5

updated 2018-05-04 13:48:50 +0000

Hi,

With this PCAP file, Wireshark (v2.6.0) shows 4 "TCP Window Full" events using the display filter "tcp.analysis.window_full".

However, I was calculating the remaining window size on my own and I have found one more "TCP Window Full" event, right in the beginning of the TCP stream.

Packet no. 68 (TCP SYN/ACK) sets the window size (downlink) to 14480 bytes. Then there are 10 x HTTP data packets (uplink, no. 70 - 79), all containing 1448 bytes of data.

With packet no. 79, I would expect a "TCP Window Full" event, visible with display filter "tcp.analysis.window_full". Can somebody explain why it doesn't?

Many thanks!

edit retag flag offensive close merge delete

Comments

Can't download your file - could you share it on cloudshark.org instead?

NJL ( 2018-05-04 12:03:35 +0000 )edit

Great, didn't know cloudshark.org... Here is the file

airshark ( 2018-05-04 12:12:54 +0000 )edit

add a comment

answered 2018-05-04 12:41:22 +0000

NJL
120 ●2 ●24 ●8

updated 2018-05-04 13:48:09 +0000

I see this as a non-issue and as perfectly normal behaviour.

The [TCP Window Full] is a Wireshark expert-generated message. It's not something seen on the wire. Remember that everything shown in square brackets in Wireshark is expert-generated, so based on what Wireshark has seen (TCP Receive Window size of 14480B in packet 68) coupled with how much data is sent (packets 70-79) the TCP receive window should now be full.

[edited due to error] However, in packet 80, the receiver now ACKs packet 70 and increases its TCP Receive Window to 17408B. This is the same for (haven't checked each and everyone) the rest of the [TCP Window Full] messages.

You shouldn't worry about this, but you should worry if you see [TCP ZeroWindow] which is essentially a message containing a TCP Receive Window size if - you guessed it - zero. That is a clear indicator that the receiver does not have enough ressources to empty its receive buffer.

Out of curiosity - where and how was this captured?

edit flag offensive delete link

Comments

Thank you for your answer.

With packet 79 the remaining window bytes are 0. With packet 80 the window size is increased and some of the packets are ACKed (sliding window). I do understand that starting with packet 81 there is again window space left.

However, I see the same pattern with the window/packets that are marked as "TCP window full", later in the stream.

I try to understand why Wireshark is marking packet 220, 254, 591 and 902 with "TCP window full", but not packet 79.

airshark ( 2018-05-04 13:09:55 +0000 )edit

Right. I'm actually not completely sure why this happens. I agree that if Wireshark flags this in packet 220 it should also do it in packet 79. Reading my answer I also see I was wrong when I wrote "However, in packet 80, the receiver now ACKs everything" as it only ACKs one packet - and it takes 22+ milliseconds to do so. That seems odd and points me to believe that 80.74.152.241 is too slow to receive what is being sent. (not the answer you were looking for - I know :-))

This is actually interesting, I'll try to dig some more.

NJL ( 2018-05-04 13:33:29 +0000 )edit

Alright, I'm not 100% sure, BUT I think the reason Wireshark doesn't flag packet 79 as TCP Window Full relates to what is being discussed in this post here: https://osqa-ask.wireshark.org/questi...

NJL ( 2018-05-04 13:46:47 +0000 )edit

Great! This sounds very reasonable.

I was not aware of WindowSize is not negotiated but WindowScale is.

Maybe the problem is that with packet 68 (SYN/ACK) there is a WindowSize 14480 announced and in the same packet the WindowScale option is confirmed/negotiated. At this point Wireshark is not yet using a calculated WindowSize but just displays the WindowSize as it was transferred. Probably the standard is not clear here on how to interpret this? And therefore, only after packet 80 where WindowSize can be interpreted as value that needs to be multiplied with WindowScale, we can ensure the WindowSize in use is real.

airshark ( 2018-05-04 14:36:34 +0000 )edit

My thoughts exactly, but I'm also not sure I'm correct.

NJL ( 2018-05-04 15:03:59 +0000 )edit

see more comments

Wireshark not showing all "TCP window full"?

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Wireshark not showing all "TCP window full"? edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Wireshark not showing all "TCP window full"?