Hi All,
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.
(refer wireshark_sample.jpg)
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 omnipeek_sample.jpg)
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
hf_peekremote_unknown1
hf_peekremote_unknown2
hf_peekremote_unknown3
hf_peekremote_unknown4
hf_peekremote_unknown5
hf_peekremote_unknown6
hf_peekremote_channel
hf_peekremote_timestamp
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)
* From:
*
http://www.cisco.com/univercd/cc/td/doc/product/wireless/pahcont/oweb.pdf
* "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,
Emburey
