Attaching the file would be useful...
From: JOHN PROKOPENKO <john.pro@xxxxxxxxxx>
To: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx>
Sent: Monday, April 16, 2012 12:19:08 AM
Subject: Wireshark 1.7.1 802.11s Decoding Bug (Mesh Control Field)
Hello,
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.
Cheers, John Prokopenko
Attachment:
Mesh_Control_Bug_cap1.pcapng
Description: Binary data
