I am examining a PCAP that is part of an 802.11 survey that was conducted in a very busy environment within public space. I have a few packets/frames that I needed to examine and upon further examination, I discovered that the wlan_mgt.ds.current_channel is different than ppi.80211-common.chan.freq within the frame.
Specifically, I have a situation where I am examining a beacon frame with those numbers being reported as channel 11 while the channel frequency is being reported as 2484. I added the custom columns to Wireshark using the syntax above to extract the information for the channel and frequency since the default "Frequency/Channel" column was reporting conflicting information.
My questions would be...
Why am I seeing conflicting information within the raw pcap file using any of the previously defined column settings, default or custom? I would like to understand if there's something that I am interpreting incorrectly when looking at the raw pcap (hex) information. If I am not misunderstanding what I am seeing, there may be an issue elsewhere in my tool set?
I read over the paper written By Devin Akin, but this scenario seems to be different in that the information within the capture itself is contradictory. https://www.cwnp.com/cmsAdmin/uploads/protection_ripple_in_erp_802-11_wlans.pdf
I would love to include a screenshot or snippet but I see no way of doing that on this forum board. The following is an exported dissection from Wireshark that has been significantly truncated:
Source Destination Protocol Length SSID B&P Channel Freq Freq/Ch-def
d8:97:ba:xx:xx:xx ff:ff:ff:ff:ff:ff 802.11 515 [removed] Beacon frame 11 2484 2484 [BG 14]
The last three columns are those that are explained in my text with the last being a default Wireshark Freq/Channel selection that I do not have specific information for, as that extracted information relates to the location within the pcap.
Any assistance would be greatly appreciated.
Unless you are in Japan where CH 14 is a legal channel, I would guess you are getting some kind of bleed over from a lower channel.
Some wireless adapters do not report PCAP headers correctly. I would suggest you try a dedicated product like OmniPeek and compare results.
Note that even in Japan CH 14 is only supposed to be 802.11b, not /g. They do have some alternative channel widths there, but I have never actually heard of any of them being used.
Is there any chance you are hunting for a Rogue AP ?
One last thought - you should ignore any packets that are flagged as having CRC errors.
Thank you for responding. A rouge AP is the analogy in this situation - yes. I am familiar with the regulations regarding "legal" channel usage, but that would not apply (directly) in this scenario.
I am using a purpose built box with (3) of these cards installed - http://www.avagotech.com/docs/12351831
It wouldn't be out of the question that these cards are reporting headers incorrectly, but I would be surprised if that were the case in this situation considering these are supposed to be higher end commercial cards. I have omni-peek and will be analyzing the pcaps... however, I am looking at the raw hex and where I can, converting the hex and coming up with the same results - manually vs automagically.
In other words, do you know that Omni-peek interprets the raw pcap differently than WS or is that an educated guess? I have used two different versions of WS within two different OSes and have received the same results. Can you or anyone here tell me where omni-peek and WS read the "default" Freq/Ch info from within the packet - or where it should be read from?
I cannot think of a test scenario outside of the paper cited in my original post that confirm or dispute my findings - specifically something that would attempt to "force" a situation where the known channel(s) would be reported incorrectly?
Thanks to all!
Remember that Wi-Fi signals do not magically stop at the "defined" channel edges. They may meet the channel mask requirements, but there is always some overlap to nearby channels.
However, the power levels are usually so low that they don't cause problems, or see them in sniffer traces.
At one crazy location at work I can see over 200 BSSID's simultaneously. If I run OmniPeek here, I definitely see traffic listed for one channel that is actually generated on another.
It depends on the EIRP of the AP's, the sniffers sensitivity & antenna gain, and the sniffers proximity to the AP.
You can usually clarify things by looking at a multitude of (MCA network) Beacons and compare the power levels shown for the same BSSID reported for the different channels. The channel reporting the highest power level will be the actual channel of that BSSID.
As to your other question - it is the case that some sniffers report differently than others. Usually the more expensive sniffer products, i.e. non-WS, will be reporting correctly on new fields sooner. In addition, they may also report manufacturer specific IE's more completely.
After that, the faster the sniffer runs the fewer frames that are missed - which also applies to the more expensive software. Usually postponing packet analysis until after the packets are collected, as opposed to real time filtering, will give you a much more realistic trace.
Also, I almost never run multi-channel scanning, unless I have multiple adapters running, each set to a single channel. OmniPeek has a way to merge these traces into one file.
The long story short...
OmniPeek did a better job than WS. Channels 12, 13 and 14 were being utilized in the environment (many, many APs) but WS was reporting some of channel to frequency mapping incorrectly, especially when the frequency was being reported as a plus or minus channel (off center freq).
The equipment is purpose built to run in multi-channel mode at a very high scan rate... multiple radios... no problem there.
I have to go over the data again to verify a few things. I believe that WS was not reporting some of the data fields correctly.
Thank you again,