Ask Your Question

TCP Window Full followed by TCP Zero Window and TCP Keep Alive

asked 2021-12-02 22:38:39 +0000

fly_agaric gravatar image

updated 2021-12-07 21:35:51 +0000

Hello Guys,

i have a trace file where an SAP Client says: "connection to partner '' broken TIME Thu Dec 02 10:33:58 2021" and "DETAIL NiIRead: P=; L= SYSTEM CALL recv COUNTER"

I do see many out of order Packets and TCP Retransmissions but from what I have seen TCP should handle it all. I have searched for tcp.port==50972 to see the stream where the connection error occurs and I see weired TCP Window followed by a TCP Keep Alive. Over 200 seconds are "wasted" for the keep alives does this mean that the client is processing something in the background? From what I understand TCP ZeroWindow means that cannot handle more data right?

image description

In the 2nd image I see a normal TCP Finish sent from both client and server. So I wonder what is wrong here? My conclusion would be that the application is sending the wrong error message because the connection is not really broken in sense of tcp. image description

I have attached a trace file where everything after layer 4 is truncated. Network Trace

Edited: Can someone tell me whats wrong with this low window size? According to 3 way handshake the client only have a window size of 8192 but in Frame 3 Client only has 259. What happend here? How is the window size calculated? How does wireshark calculate 259?

image description

Edited2: Yes Ip does support window scaling with a factor of 7 image description

Edited3: The Screenshot of the TCP events before 44877: image description

Edited4: image description

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2021-12-03 00:53:31 +0000

BigFatCat gravatar image

I wasn't unable to download the pcap. Adding a column for bytes-in-flight or tcptrace graph might help visually. Wireshark tracks bytes-in-flight and the window size. Wireshark "TCP Window Full" is Wireshark's way of saying that the sender can't send any more data because it has fill the advertised window.

Frame 44967, Wireshark is saying can't send any more data because it has filled advertised window. The client,, has to wait for an update from before it can send more data. Frame 44968, is advertising the window size 0. Don't send me any data. Frame 44969, sends TCP Keep-Alive because it is waiting for to an update. Also, this ensures it didn't miss the update. Frame 46149, updates its window size. starts sending data again.

I suggest increasing the window size for If that isn't possible, find out why it's having problems processing packets.

edit flag offensive delete link more


Okay thanks for your answer. is a Windows Server 2016. As far as I know i cannot change the window size directly because of auto tuning. I have found old Registry Keys which are for NT and 2003 but not for Server 2016 and above. This page "" says that I can change the window scale factor with netsh interface tcp set global autotuninglevel=<value> where Value is per default "normal" with a scale factor of 8. I could set it to "Experimental" where scaling factor is 14</value>

fly_agaric gravatar imagefly_agaric ( 2021-12-03 02:08:03 +0000 )edit

Can someone tell me whats wrong with this low window size? According to 3 way handshake the client only have a window size of 8192 but in Frame 3 Client only has 259. What happend here? How is the window size calculated? How does wireshark calculate 259? link text

fly_agaric gravatar imagefly_agaric ( 2021-12-03 17:50:18 +0000 )edit

There is a window scale factor of 8 (WS=256) shown in the SYN message INFO area. I didn't see that in the SYN message (INFO column is cut-off in the screenshot). You have to check the TCP options in the SYN message to see if it is there. The window scale rule requires both sides to advertise the option. If doesn't advertise window scale, then it is not used. Enabling it could resolve the problem if it was not enabled.

BigFatCat gravatar imageBigFatCat ( 2021-12-03 19:07:42 +0000 )edit

Yes Ip does support window scaling with a factor of 7. What else could it be that the Receive Window of my client is so small?

fly_agaric gravatar imagefly_agaric ( 2021-12-03 19:15:56 +0000 )edit

I am looking at picture 1 again. Were there any TCP events before frames 44877,44899, 44902? The server acknowledges that it received the segments, but the Receive Window size is not increasing. It shouldn't need four minutes for the window size zero issue to clear. It might be worth investigating what was utilizing the server resources? Because everything else looks right.

BigFatCat gravatar imageBigFatCat ( 2021-12-05 10:48:01 +0000 )edit

Well I see some "TCP previous segment not captured" followed by TCP Dup Ack and TCP Retransmissions and some TCP Out of Order Packets. I have posted the screenshot above.

fly_agaric gravatar imagefly_agaric ( 2021-12-05 11:41:24 +0000 )edit

The new screenshot partially explains the behavior of the server. The server is saying that it is missing packets with duplicate ACKs and SACKs. Delivery of data to the application will be delayed because of this. If segments 1-10 and segment 6 are dropped, this is a brief explanation. Until segment 6 is received, it won't send segments 7 to 10. This shouldn't result in 4 minutes of window-size-zero.

Return to your original question. Search for a pattern. Are there other captures with the same issue? Does it happen after there are several transmissions? If there is a pattern, then check if the application has an option when it thinks there is a problem with the connection?

BigFatCat gravatar imageBigFatCat ( 2021-12-07 01:28:23 +0000 )edit

The issue always appears like 5 to 6 mins after the tcp sessions were established. I did the following: I have changed the TCP Profile for the Destination IP from Internet to Datacenter. After I have changed it to Datacenter no TCP Window Zero Issues occur anymore. The Calculated Window Size changed from ~64k to ~4M. In the trace then I only have seen WindowUpdates but no Zeros.

The Application Error Message "connection to partner '' broken went away. Could someone tell me why the connection breaks when the Internet Profile is used?

PS C:\Windows\system32> Get-NetTCPConnection | findstr 3300 53912 3300 Established Internet 15080

PS C:\Windows\system32> New-NetTransportFilter -SettingName Datacenter -DestinationPrefix PS C:\Windows\system32> Get-NetTCPConnection | findstr 3300 53961 ...(more)

fly_agaric gravatar imagefly_agaric ( 2021-12-07 21:31:17 +0000 )edit

If I understand correctly. The server started sending a window size of 4M after changing the profile. Before the change, it was 64k. The CTCP and DCTCP were developed by Microsoft. Is, an MS or Linux server? I listed MS explanations below. They don't explain the behavior with the zero window.

MS explanation

Congestion Provider CTCP. Compound TCP increases the receive window and amount of data sent. CTCP can improve throughput on higher latency connections. DCTCP. Data Center TCP adjusts the TCP window based on network congestion feedback based on Explicit Congestion Notification (ECN) signaling. DCTCP may improve throughput on low latency links.

CWNDRESTART Specifies whether to enable congestion window restart. Congestion window restart can avoid slow start to optimize throughput on low latency networks. True. TCP uses congestion window restart. False. TCP uses the default setting of the connection.

ForcedWS Specifies whether to force ...(more)

BigFatCat gravatar imageBigFatCat ( 2021-12-08 23:25:29 +0000 )edit is a Windows Server 2016. The other side is a linux os red hat. The application developer told me that the first job from the client was fixed but the 2nd one which transfers bigger transfer which still fails. I captured with wireshark again and I see the same as I did before I fixxed Job 1 many TCP Zero Windows and Packetloss. I have tried autotuning=experimental and DataCenter TCP but I cannot go higher then 4M for some reason for the window size.

fly_agaric gravatar imagefly_agaric ( 2021-12-09 19:41:37 +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



Asked: 2021-12-02 22:38:39 +0000

Seen: 4,158 times

Last updated: Dec 07 '21