Comment # 7
on bug 11397
from Christopher Maynard
(In reply to Evan Huus from comment #6)
> I've uploaded a change to only reset the dupack counter when the ack number
> changes (fixes this issue), but I do not have any other dupack captures
> handy to test with, so it's possible (read: likely) it broke some other case
> instead.
>
> I'd appreciate somebody taking a poke through a few more test cases with
> this code to make sure it works as intended, the TCP analysis logic is
> finicky.
You can also test with the capture file I posted with bug 1847. I tested it and
it definitely helps; however, it looks to me like things are still not quite
right in all cases. For example, if you follow my analysis from
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1847#c2, shouldn't frames
#18, #43 and #79 also be marked as DUP ACK's? The ACK # hasn't changed since
frame 15. I guess the problem is that the PSH bit is set for all 3 of those
frames, so that is the reason?
You are receiving this mail because:
- You are watching all bug changes.