I captured a TCP session that was throttled by the receiver using TCP ZeroWindow. Subsequently the sender probed two times, using ZeroWindowProbe including the next data byte. When the receiver finally opened the window, transmission resumed as usual. During the probing, ACK and SEQ numbers did not increment, as expected. In wireshark when I "Follow TCP stream" and then save the stream as raw, one of the two probing data bytes are included in the file. Why is that? Shouldn't they be omitted like re-transmitted data? And if not, why would there only be one of the two additional bytes? Here is a sanitized capture demonstrating the issue: https://www.dropbox.com/s/b8qubwtdi5nucqx/zwin2_anon.pcapng?dl=0 After saving the stream, you can find the duplicated byte by searching for "0x50 0x50". asked 14 Jul '17, 11:47  namnamreg edited 17 Jul '17, 08:52 |
One Answer:
Zero Window is the receiving system saying that it's receive buffer is full and it has no room for incoming data. Naturally, this stops the data transfer. When the receiving system has space in its receive buffer again, it will send a Window Update. It's possible that, due to packet loss, the sending system might not get the window update, so the sending system will send Zero Window Probes periodically, just to check if the receiver's buffer is still full. It's asking the receiver "Are you still out of space, or can I resume sending?" Zero window probes contain the next one byte of data. If the receiving system now has space in its receive buffer, it will accept that byte of data, increment the ACK by one, and put its current window size in the window size field. If the receiving system is still out of space, it will not have room for that byte of data, so it will send back an acknowledgment but the ACK number will not increase, indicating that it did not accept the byte of data, and again putting zero in the window size field. The ACK did not increase because the two data bytes were not accepted. When the communication resumed, you only saw one of the two bytes because both of the zero window probes contained the same byte of data. It was not accepted either time. answered 14 Jul '17, 14:18  Jim Aragon |
Maybe I wasn't clear, the actual data byte in question is sent three times: First and second time with the probes (ACK does not increment, like you pointed out), and then again when the window opens, as first byte of the next full data packet. So, on the receiving end's application layer I only see that byte once, as expected. However when I save the captured stream in wireshark, I see it twice. So my conclusion is that one of the two probe bytes is being interpreted as data when the stream gets reassembled, but it shouldn't.
That sounds like a bug. I suggest you submit a bug report at https://bugs.wireshark.org/bugzilla/
Or you can share us the example https://blog.packet-foo.com/2016/11/the-wireshark-qa-trace-file-sharing-tutorial/
Thanks, I wasn't aware of that great tool! I edited the question and added a link to a sample.
It seems that Wireshark is getting confused. The Zero Window Probes are in packets 20 and 22. If you follow the stream and then switch the display to "C Arrays" you will see each packet listed with a note in the form "/ Packet n /", where "n" is the packet number. Packet 22, the second Zero Window Probe, is missing. Every other packet is listed, whether it has data or not. This looks like a bug to me, and I assume that the same bug is responsible both for the missing packet in the Follow Stream C Arrays display, and for the fact that one of the Zero Window Probes is saved as data.