Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: [Wireshark-dev] TCP ZeroWindowProbe problem / question

From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Tue, 20 Feb 2007 07:41:21 +0100
Hi List!

As I'm not an expert on TCP, I have a problem which seems to be related to the TCP's ZeroWindowProbe mechanism. As I digged deeper into the docs, I've found a difference between our Wiki and the TCP RFC (well, and a lack of knowledge on my side on this topic).


To quote our Wiki http://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers: "TCP ZeroWindowProbe <http://wiki.wireshark.org/TCP_ZerowindowProbe> - The sender is testing to see if the receiver's zero window condition still exists by re-sending the last byte of data to elicit a duplicate ACK from the receiver. If the window is still zero, the sender will double his timer before probing again."

I read this as: the sender sends the last already ACK'ed ("old") byte again and the receiver ACKs this "old" byte just again (usually the same ACK and Windows Size values than in the "last ACK packet").

This is in contrast to the part of RFC 793 which states (fourth section under "Managing the Window"):

 The sending TCP must be prepared to accept from the user and send at
 least one octet of new data even if the send window is zero.  The
 sending TCP must regularly retransmit to the receiving TCP even when
 the window is zero.  Two minutes is recommended for the retransmission
 interval when the window is zero.  This retransmission is essential to
 guarantee that when either TCP has a zero window the re-opening of the
 window will be reliably reported to the other.

 When the receiving TCP has a zero window and a segment arrives it must
 still send an acknowledgment showing its next expected sequence number
 and current window (zero).


I read this as: the sender sends a single *new* byte but the receiver ACKs the "old" byte again (usually the same ACK and Windows Size values than in the "last ACK packet").


So about the following things I'm a bit unsure about:
- which byte does the sender send? The last old byte again or a new byte in the stream? - will the ACK number of the receiver be increased because of the zero window probe byte? (I wouldn't expect it that way - as the Windows size is 0, the receiver don't have space even for this byte)


If anyone with some more knowledge on this could share some light, it would really be helpful (Ronnie?) ...

Regards, ULFL