Wireshark-bugs: [Wireshark-bugs] [Bug 7768] New: ieee802.11 dissector field size issues
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7768
Summary: ieee802.11 dissector field size issues
Product: Wireshark
Version: SVN
Platform: x86
OS/Version: Windows XP
Status: NEW
Severity: Minor
Priority: Low
Component: Dissection engine (libwireshark)
AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
ReportedBy: mmann78@xxxxxxxxxxxx
Michael Mann <mmann78@xxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #9245| |review_for_checkin?
Flags| |
Created attachment 9245
--> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=9245
Updated ieee802.11 dissector fields for a "16-bit boundary"
Build Information:
Version 1.9.0 (SVN Rev 45175 from /trunk)
Copyright 1998-2012 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 (32-bit) with GTK+ 2.24.10, with Cairo 1.10.2, with Pango 1.30.0, with
GLib 2.32.2, with WinPcap (4_1_2), with libz 1.2.5, without POSIX capabilities,
without libnl, with SMI 0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python,
with GnuTLS 2.12.18, with Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with
PortAudio V19-devel (built Sep 25 2012), with AirPcap.
Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1.2
(packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b
(20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap.
Built using Microsoft Visual C++ 9.0 build 30729
--
There are a handful of fields in the IEEE802.11 dissector that are comprised of
a 16-bit value. The hf array for these fields has the necessary masks to
correctly parse a 16-bit value, yet some of the fields were being added as 1
byte. This patch corrects these fields with a proto_tree_add_item approach
(instead of proto_tree_add_[uint|boolean]).
The two fields I'm still not sure of are
hf_ieee80211_block_ack_control_multi_tid_info and
hf_ieee80211_block_ack_control_compressed_tid_info.
Per http://standards.ieee.org/getieee802/download/802.11n-2009.pdf, Chapter
7.2.1.7.4, "number of TIDs present" (which is what the above hf_ variables
represent) is the TID_INFO field + 1. Now the TID_INFO field is the last 4
bits of the 16-bit BAR control field, but these hf_ variables represent a
"computed" value. How should the dissector note the field is the last 4 bits,
yet could have a value greater than 15? Should the hf_ variables not bother to
have a mask, and the TID_INFO field should really be treated as only a byte?
Can't Wireshark highlight just a nibble, in which case the mask is important?
The provided patch fixes the other fields that were known problems, but makes a
"best effort" to fix the TID_INFO field for Multi-TID BlockAck (in an attempt
to remove the unnecessary decode_numeric_bitfield()).
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
