[bugzilla-daemon@xxxxxxxxxxxxx]

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.