mailing list archives
Change of decoding for Airopeek/Omnipeek 802.11 header with Cisco APs
From: "Emburey Samrex Edward -X (emedward - EMBED UR SYSTEMS at Cisco)" <emedward () cisco com>
Date: Thu, 19 Dec 2013 15:26:37 +0000
Thanks for attention!
This is regd the PEEKREMOTE decoding of the header Airopeek/Omnipeek encapsulated IEEE 802.11.
On capturing the sniffed o/p of Cisco APs, with PEEKREMOTE decoding, the 802.11 headers are not properly classified.
This must take place under the header Airopeek/Omnipeek encapsulated IEEE 802.11.
In contrast, in an Omnipeek capture, it is well classified (under one of its header Cisco AP 802.11n). (refer
We rightly have the same hexdump been populated in wireshark, like that in omnipeek.
So, the existing classification/decoding for the header Airopeek/Omnipeek encapsulated IEEE 802.11, within wireshark
would need to be scrutinized.
The file trunk/epan/dissectors/packet-peekremote.c handles the decoding for this header.
The following are the variables, behind the header
At the function dissect_peekremote() we can include more decoding for snr/rssi/datarate/channel/timestamp values, which
can then be forwarded to proto_register_peekremote() appropriately.
There is also a TBD note at the starting note of this packet-peekremote.c file, that infers a similar case.
* TODO: Decode meta information.
* Check on fillup bytes in capture (fcs sometimes wrong)
* "It will include information on timestamp, signal strength, packet size
* and so on"
Can someone please clarify on the purpose of the existing decoding, and now adapt for this suggested one - so as to get
a proper classification of the Airopeek/Omnipeek encapsulated IEEE 802.11 header with Cisco APs in wireshark.
Thanks in advance,
Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org>
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
- Change of decoding for Airopeek/Omnipeek 802.11 header with Cisco APs Emburey Samrex Edward -X (emedward - EMBED UR SYSTEMS at Cisco) (Dec 19)