Wireshark-bugs: [Wireshark-bugs] [Bug 9586] New: Need more classification of fields within Airop
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Sat, 21 Dec 2013 17:17:53 +0000
Bug ID 9586
Summary Need more classification of fields within Airopeek/Omnipeek encapsulated IEEE 802.11 header
Classification Unclassified
Product Wireshark
Version 1.10.4
Hardware x86
OS Windows 7
Status UNCONFIRMED
Severity Major
Priority Low
Component Wireshark
Assignee bugzilla-admin@wireshark.org
Reporter emedward@cisco.com 

Created attachment 12363 [details]
Comparison of both 20-byte & 55-byte headers display in omnipeek

Build Information:
Paste the COMPLETE build information from "Help->About Wireshark", "wireshark
-v", or "tshark -v".
--
The PEEKREMOTE decoding, on the sniffed output of a Cisco AP, is not
classifying the 802.11 radio headers in an informative way.

We can find this within the header 'Airopeek/Omnipeek encapsulated IEEE
802.11'.
Right now, it has some unknown fields, and the existing channel/timestamp are
not accurate.

Basically, the field gets one of the 2 different length headers: a 20 byte (the
legacy header), and a 55-byte (the 802.11n supported header)

The 55-byte header, starts with a fixed magic number (00ffabcd); it does not
exist in the 20-byte legacy header. Hence both these headers can be
differentiated with this magic number (this can be utilized in different
dissections for these headers).

Now, we would need to change the dissection within dissect_peekremote() at
trunk/epan/dissectors/packet-peekremote.c - to represent the fields, as done in
an understandable manner by Omnipeek (PFA the
compare_80211n_legacy_omnipeek.png which illustrates the proper dissection from
an omnipeek pkt capture)

You are receiving this mail because:
  • You are watching all bug changes.