Bill Meier
changed
bug 10745
| What |
Removed |
Added |
| Status |
UNCONFIRMED
|
IN_PROGRESS
|
| See Also |
|
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8404, https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11506, https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6774
|
| Ever confirmed |
|
1
|
Comment # 2
on bug 10745
from Bill Meier
(In reply to Jasper Bongertz from comment #1)
> (In reply to dbk7 from comment #0)
>
> Zero Window Probes can be performed in two ways:
>
> 1. Sending the last already acknowledged byte
Wireshark doesn't recognize this case; This is a bug to be fixed
> 2. Sending the next byte after the last already acknowledged byte
>
> in both cases, the Zero Window Probe ACK number must be the same as the ACK
> in the Zero Window packet. This is obvious, since the window is full and a
> new byte (as in 2.) cannot be accepted and must be discarded while sending
> back the ACK for the byte before.
>
For case 2, poking around the web a bit suggests that the receiver may accept
(consume) the "next byte" even though the window is full.
For example, see https://bugzilla.redhat.com/show_bug.cgi?id=537145
(I note that there are other traces which show this behavior.
E.G., See: Bug #8404: 2nd attached capture file: error.pcap)
Wireshark doesn't handle this case properly, either.
> In your trace, the receiver DOES acknowledge the new byte (which should be
> impossible, as it goes beyond the receive window), and my guess is that this
> breaks the Zero Window Probe / Zero Window Probe ACK detection code in
> Wireshark.
> You can also see "TCP ACKed unseen segment" messages that make no
> sense, because there's nothing missing - there is one byte too much instead.
I believe this is another Wireshark bug (since the byte was actually sent (and
seen) and accepted).
See Bug #8404: First attached capture
You are receiving this mail because:
- You are watching all bug changes.