On Dec 19, 2013, at 7:26 AM, Emburey Samrex Edward -X (emedward - EMBED UR SYSTEMS at Cisco) <emedward@xxxxxxxxx> wrote:
> 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:
http://bugs.wireshark.org/
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.