Wireshark-bugs: [Wireshark-bugs] [Bug 10745] Wrong packet analysis observed after zero window pr
Jasper Bongertz
changed
bug 10745
| What |
Removed |
Added |
| CC |
|
jasper@packet-foo.com
|
Comment # 1
on bug 10745
from Jasper Bongertz
(In reply to dbk7 from comment #0)
> Started HTTP download with Chrome then paused.
> Wrong packet analysis observed after zero window probe is acknowledged once.
>
> packet #2532 - should be TCP ZeroWindowProbe
>
> packet #2534,2536,2538, .... - should be TCP ZeroWindowProbe
I'm not sure Wireshark is at fault here - this may be just an odd example that
isn't handled properly yet.
Zero Window Probes can be performed in two ways:
1. Sending the last already acknowledged byte
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.
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.
The packets in 2534,2536, 2538 etc. are now labeled "keep alive" because
they're the "new" byte over and over again.
I guess the best way to handle this case would be to have Wireshark detect the
anomaly of the Zero Window Probe byte (as in 2.) being acknowledged by mistake.
You are receiving this mail because:
- You are watching all bug changes.
