On 2/20/07, Ulf Lamping <[EMAIL PROTECTED]> wrote: > 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?
It sends a new byte. > - will the ACK number of the receiver be increased because of the zero The ACK will be increased to cover the new byte IFF the zero window condition has ceased (windows have been opened) The ACK will be a repeat of the previous one, repeating the ACK prior to the ZeroWindowProbe if the receiver still ahs a zero window condition and could not handle/accept the new byte. > 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) Correct. So if the window is still zero, the ACK will indicate this by NOT advancing to cover the new byte. If the window is no longer zero, the receiver can handle the byte and the ACK will be advanced to cover the new byte. > > > If anyone with some more knowledge on this could share some light, it > would really be helpful (Ronnie?) ... I will fix the WIKI when i get to a more modern computer than my home one. Konqueror 3.0 does not like wiki things :-( _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev