https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7115
Summary: 802.11s Decoding Bug (Mesh Control Field)
Product: Wireshark
Version: 1.7.x (Experimental)
Platform: x86-64
OS/Version: Windows 7
Status: NEW
Severity: Normal
Priority: Low
Component: Wireshark
AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
ReportedBy: john.pro@xxxxxxxxxx
Created attachment 8231
--> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=8231
AirPcap trace referenced in description
Build Information:
Version 1.7.1 (SVN Rev 41970 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 (64-bit) with GTK+ 2.22.1, with Cairo 1.10.2, with Pango 1.28.3, with
GLib 2.26.1, with WinPcap (4_1_2), with libz 1.2.5, without POSIX capabilities,
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, without Kerberos, with GeoIP, with PortAudio
V19-devel (built Apr 6 2012), with AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, 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, with AirPcap 4.1.1 build
1838.
--
There seems to be a bug in Wireshark 1.7.1 decoding 802.11s data frames
generated with compart-wireless daily build 2012_04_09.
Please let me know how best to log the bug.
Examing packets sent to/from nodes external to the mesh the address extension
mode bits are being incorrectly decoded.
Refering to the official 802.11s specification:
7.1.6.3 Mesh Control Field and Table 9-3
While section 7.1.6.3 Table 7-6g1 is ambigous the convention in 802.11-2007 is
that the table values stating (binary) are in "natural binary" (i.e. b1b0).
*** Referring to the attached capture file. ****
There are (at least) three cases:
When ToDS_FromDS field = 11 (binary) and Address Extension Mode subfield = 0x02
(binary 10) there are two extra addresses (A5 and A6) contained in the Mesh
Control Field.
Looking at record 10 of the attached AirPcap one can see that the addresses are
in fact contained in the record but are not displayed (note: the address are
the correct ones).
Similarly looking at record 1when Address Extension Mode subfield = 0x00
(binary 00) two addresses are incorrectly displayed (i.e. the following LLC
fields are displayed).
Record 3 is another case from9.22.3 of the 802.11s spec Also when Address
Extension Mode subfield = 0x01 address A5 is not displayed (A5 is correctly
part of the record (f4:6d:04:99:ae:bb).
See NOTE 3 as to why the 4th address is stored in the Mesh Control Field.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.