This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Zero window and RST

0
1

Hi Experts,

I am facing with the follwoving contradiction. In RFC 793 can be read the following sentences:

once: "all reset (RST) segments are validated by checking their SEQ-fields. A reset is valid if its sequence number is in the window."

on other part of the doc: "However, when the receive window is zero, a TCP must process the RST and URG fields of all incoming segments"

Which is "more" true?

My exact problem is, that I have to decide, and declare which device is wrong (a client or Cisco ACE). The problem begins, when the server (ACE) sends a FIN. The communication looks like this (client:100.1.1.7):

  1 19:30:57.486 100.1.1.7             100.1.1.2             64    TCP      51591 > 33067 [SYN] Seq=0 Win=0 Len=0 MSS=1400
  2 19:30:57.498 100.1.1.2             100.1.1.7             64    TCP      33067 > 51591 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460
  3 19:30:57.532 100.1.1.7             100.1.1.2             64    TCP      51591 > 33067 [ACK] Seq=1 Ack=1 Win=4095 Len=0
  4 19:31:00.720 100.1.1.7             100.1.1.2             201   TCP      51591 > 33067 [PSH, ACK] Seq=1 Ack=1 Win=4095 Len=143
  5 19:31:00.781 100.1.1.2             100.1.1.7             64    TCP      33067 > 51591 [ACK] Seq=1 Ack=144 Win=8192 Len=0
  6 19:31:00.797 100.1.1.2             100.1.1.7             140   TCP      33067 > 51591 [PSH, ACK] Seq=1 Ack=144 Win=8192 Len=82
  7 19:31:00.800 100.1.1.2             100.1.1.7             64    TCP      33067 > 51591 [FIN, ACK] Seq=83 Ack=144 Win=8192 Len=0
  8 19:31:00.863 100.1.1.7             100.1.1.2             64    TCP      51591 > 33067 [ACK] Seq=144 Ack=83 Win=4013 Len=0
  9 19:31:00.874 100.1.1.7             100.1.1.2             64    TCP      [TCP ZeroWindow] 51591 > 33067 [ACK] Seq=144 Ack=84 Win=0 Len=0
 10 19:31:04.381 100.1.1.7             100.1.1.2             64    TCP      51591 > 33067 [RST] Seq=145 Win=0 Len=0
 11 19:31:04.382 100.1.1.2             100.1.1.7             64    TCP      [TCP ZeroWindow] 33067 > 51591 [ACK] Seq=84 Ack=144 Win=0 Len=0

The client doesn't replies normally to the FIN, it replies wit a simple ACK (#8), with unchanged ACK field. Furthermore it sends a zero window ACK (#9) where Ack+1. This window size shouldn't influence the server side rcv.wnd, which was 8192 in packet #6 and #7. Here comes the worst, that the server ignores the incoming (#10) RST packet (comes with Ack+1), and pretends like the sesion is still open. In the next message (#11) server sets zero window as well with seq=144) This is my question: should the server process this RST? What is the server side rcv.wnd size when the RST arrives, and if it were zero, shuld have process the RST if that has an out-of-window seq or not? (server ack=144+0 win.siz. incoming RST seq=145). This is a special communication, where the client and server uses fixed TCP src and dst ports, thus the client cannot re-estabilis a conn, until the server runs on timeout (several minutes).

The converstaion follows like this:

 12 19:42:14.450 100.1.1.7             100.1.1.2             64    TCP      [TCP Port numbers reused] 51591 > 33067 [SYN] Seq=0 Win=0 Len=0 MSS=1400
 13 19:42:14.450 100.1.1.2             100.1.1.7             64    TCP      [TCP ZeroWindow] 33067 > 51591 [ACK] Seq=1 Ack=3592380271 Win=0 Len=0
 14 19:42:16.596 100.1.1.7             100.1.1.2             64    TCP      51591 > 33067 [SYN] Seq=0 Win=0 Len=0 MSS=1400
 15 19:42:16.596 100.1.1.2             100.1.1.7             64    TCP      [TCP ZeroWindow] 33067 > 51591 [ACK] Seq=1 Ack=3592380271 Win=0 Len=0
 16 19:42:18.622 100.1.1.7             100.1.1.2             64    TCP      51591 > 33067 [SYN] Seq=0 Win=0 Len=0 MSS=1400
 17 19:42:18.622 100.1.1.2             100.1.1.7             64    TCP      [TCP ZeroWindow] 33067 > 51591 [ACK] Seq=1 Ack=3592380271 Win=0 Len=0
 18 19:42:22.893 100.1.1.7             100.1.1.2             64    TCP      51591 > 33067 [SYN] Seq=0 Win=0 Len=0 MSS=1400
 19 19:42:22.893 100.1.1.2             100.1.1.7             64    TCP      [TCP ZeroWindow] 33067 > 51591 [ACK] Seq=1 Ack=3592380271 Win=0 Len=0
 20 19:42:30.896 100.1.1.7             100.1.1.2             64    TCP      51591 > 33067 [SYN] Seq=0 Win=0 Len=0 MSS=1400
 21 19:42:30.896 100.1.1.2             100.1.1.7             64    TCP      [TCP ZeroWindow] 33067 > 51591 [ACK] Seq=1 Ack=3592380271 Win=0 Len=0

etc.

Thank you for your help in advance.

BR: jonagy

asked 12 Oct '11, 09:43

jonagy's gravatar image

jonagy
6123
accept rate: 0%

edited 29 Feb '12, 19:25

cmaynard's gravatar image

cmaynard ♦♦
9.4k1038142

@ jonagy: Still an issue?

(02 Mar '12, 10:59) Landi

not really, without final conclusion

(06 Mar '12, 01:11) jonagy

One Answer:

1

From what I see:

  • The Server sending a FIN in #7 means "no more data from me", so the zero window from the client in #9 is perfectly fine, though unusual - but since no more data from the other side it is ok
  • The RST from the server in #10 though doesn't have a matching SEQnr. because it should ne 144 there. Normally wihtin rec. window this should not be a problem, but if you take a look at the delta time between #10 and #11, you see that the RST cannot have yet arrived at the other side when you see the window update in #11, setting rec.window to zero. Here I see the issue, because after the FIN in #7 over 3 seconds passed with the other side sending no data, which could have triggered the rec.window being set to zero (just a guess). Anyways -> the RST is out of the rec.window with SEQnr. 145, so I guess that's why is is not accepted and the session is still open.

answered 06 Mar '12, 01:27

Landi's gravatar image

Landi
2.3k51442
accept rate: 28%

edited 06 Mar '12, 01:27

thank you for sharing your views on this.

(06 Mar '12, 02:06) jonagy