RST Packets with zero window length

My conclusion would be that the RST packets with zero window length are not a symptom of overload of the .26 machine.

Use the following display filter:

tcp.flags.reset == 1 and tcp.window_size == 0 and ip.addr == 10.5.220.26 and tcp.seq > 2

This will show you only RST packets which aren't the only ones belonging to their TCP session in the capture and where the client->server data of the session are present in the capture, so you have a chance to see what had happened in their respective sessions before the RST packets came.

Now find sessions where the tcp.seq in the RST packet is below 3000. These seem to be conversations where both the SOAP request and response have been captured and where only a single session over a given socket pair has been captured; where the tcp.seq in the RST packet is much higher, you'll see that the socket pair has been reused.

Now find the tcp.stream value for any of them (e.g., 85) and use this value to show the whole stream, using a display filter tcp.stream == 85.

You'll see an almost normal exchange - the client sets up the session and sends a SOAP request, and it sends a FIN after it receives an ACK for the last segment of the request, indicating that it is not going to send anything else using this session. What is strange is that the client (.26) sends the packet with FIN exactly 10 seconds after getting an ACK to the last segment of the request, and that the server (.199) doesn't start sending the response until it receives that FIN from the client.

After the server (.199) finishes sending its response, it sends its own FIN. Normally, the client should send an ACK to that FIN and the session would be completely closed. Instead, it sends a RST (with window size = 0, but that's not important because the server has already sent FIN so it is not going to send data any more). That may be a way to avoid the tcp wait state which normally follows peaceful closure of a TCP session to provide a guard period to avoid confusion of packets belonging to two distinct TCP sessions using the same socket pair.

If you filter using tcp.stream == 73, you'll see a slightly different picture (several SOAP requests and responses in a single TCP session) but still with the 10 seconds gap before the client sends its FIN and still with the client responding with RST to server's FIN.

Why I don't think that the RST with window size 0 indicates an overload of .26:

• because the .26 sends window size 0 after receiving FIN from the opposite end so it is actually irrelevant,
• because the .26 is a client in the sessions so if it would be overloaded, it would stop opening new sessions at first place.

On the other hand, I do admit that the capture contains also cases where, in an otherwise same pattern, the window size in client's RST is different from 0.

The 10 second gap before sending the FIN seems to be a guard period for eventual other requests to come from the application. What is strange is that although the last segment of the request bears a PSH flag, the server does not respond immediately but only after receiving the FIN flag. This is only the case for the last request in the session, so maybe it is related to the particular type of that request?