Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 7115] New: 802.11s Decoding Bug (Mesh Control Field)

Date: Mon, 16 Apr 2012 09:04:41 -0700 (PDT)
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.