http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1694
Summary: TCP does NOT decode correctly in the presence of 802.11
retry frames
Product: Wireshark
Version: 0.99.6
Platform: PC
OS/Version: All
Status: NEW
Severity: Major
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: steven.leung@xxxxxxxxxxxx
Build Information:
Version 0.99.6
Copyright 1998-2007 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GTK+ 2.10.11, with GLib 2.12.11, with libpcap 0.9.5, with libz
1.2.3, with libpcre 7.0, with Net-SNMP 5.3.1, with ADNS, without Lua, with
GnuTLS 1.6.1, with Gcrypt 1.2.4, with MIT Kerberos, with PortAudio <= V18,
without AirPcap.
Running on Linux 2.6.17-13mdv, with libpcap version 0.9.5.
Built using gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1).
--
TCP decode does NOT take into account that some of the 802.11 frames are
captured but not acknowledged at the 802.11 level. Only the last 802.11 frame
of the same sequence number should be used for upper layer decode. Currently,
TCP decode incorrectly shows a lot of duplicate TCP ACKs, retransmissions out
of order frames. To reproduce this, a good 802.11 NIC is needed which captures
good and bad frames and all the 802.11 ACKs. Of course there need to be TCP
frames.
It looks OS independent. I know that this happens on Linux and Windows XP.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.