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

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

fly_agaric
1 ●4 ●7 ●6

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

Hello Guys,

i have a trace file where an SAP Client says: "connection to partner '1.27.223.175:3300' broken TIME Thu Dec 02 10:33:58 2021" and "DETAIL NiIRead: P=1.27.223.175:3300; L=192.5.10.69:50972 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 192.5.10.69 is processing something in the background? From what I understand TCP ZeroWindow means that 192.5.10.69 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 192.5.10.69 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 1.27.223.175 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

add a comment

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

BigFatCat
31 ●2 ●88 ●4

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

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

edit flag offensive delete link

Comments

Okay thanks for your answer. 192.50.10.69 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 "https://docs.microsoft.com/en-us/wind..." 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 ( 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 192.5.10.69 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 ( 2021-12-03 17:50:18 +0000 )edit

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

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

Yes Ip 1.27.223.175 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 ( 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 192.50.10.69 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 ( 2021-12-05 10:48:01 +0000 )edit

see more comments

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

1 Answer

Comments

Your Answer

Question Tools

Stats

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

1 Answer

Comments

Your Answer

Question Tools

Stats

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