mailing list archives
Re: Change of decoding for Airopeek/Omnipeek 802.11 header with Cisco APs
From: Guy Harris <guy () alum mit edu>
Date: Thu, 19 Dec 2013 11:54:10 -0800
On Dec 19, 2013, at 7:26 AM, Emburey Samrex Edward -X (emedward - EMBED UR SYSTEMS at Cisco) <emedward () cisco com>
Can someone please clarify on the purpose of the existing decoding,
The purpose is to attempt to do something more than just say "random UDP packet" for those packets.
The first checkin comment is:
Beginnings of airopeek remote capture support.
The metainformation is not yet decoded, also, there
are problems with QoS frames (extra bytes).
I infer from that comment and a later comment:
- All Frames that I currently know how to dissect include the FCS
- Decode Channel and (what probably is the) Timestamp
that Joerg wrote that dissector by reverse-engineering the protocol, and might not have had a copy of Airopeek or
Omnipeek available to help in the reverse-engineering process. Reverse-engineering is easier the more information is
available, and there might be limits on how much can be done with limited information.
and now adapt for this suggested one – so as to get a proper classification of theAiropeek/Omnipeek encapsulated IEEE
802.11 header with Cisco APs in wireshark.
Now that you've provided an example of how Omnipeek dissects the same packet, we now have more data, probably
sufficient to allow us to correctly dissect the packet, and can improve the dissection of the "Peek remote" protocol.
Thank you for providing that additional information.
If you could file a bug on this at the Wireshark Bugzilla:
and, at minimum, attach the screenshots from this mail, that would be helpful. If you could attach the capture file
that was decoded in the Omnipeek example, that would be better - and if you could attach, or provide a URL for, an
*explicit specification* for the protocol, that would be ideal.
Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org>
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe