I am monitoring the 802.11 traffic in my network, and especially the active probing from my smartphone. I am sending Probe Requests for certain hidden SSIDs, but also an Undirected Probe Request, supposed to reveal networks matching the capabilities announced by my device.

I am in Europe, so we get to use more channels than in the US I think (right?) and thus they overlap.

As expected, the scanning takes place on different channels in turn, but what surprises me is this behaviour:

An undirected probe request sent on channel 5 is answered by an AP on channel 6. Is this completely normal behaviour i.e. defined anywhere in the official specs?

EDIT: Here is the content of both probe request and response, I am basing my assumption on the DS Parameter Set: Current Channel. Picture on i.imgur

The time difference between the two frames is 4ms, and I did not observe any other activity on the waves during this time period.

EDIT: Here is the command I run with airodump-ng 1.0 airodump-ng -c 6 mon0

and the capture tool shows beacons coming from APs on channel 2 to 9. To me it means that airodump accepts all packets visible on a frequecy range, without dismissing them according to the Current Channel Parameter, makes sense for performance reasons.

If the router has the same behaviour for answering probe requests... this may be why. (Starting to question the selectivity of the frequency filters used in our beloved routers.)


Is this behaviour 1) repeatable, could someone with a working device please try to observe this ? 2) specified somewhere in the 802.11 references ? Could not find it my self.


Thanks to everyone so far who tried repeating this setup. Here is my last attempt at getting an explanation to this. I need to move on :P Here is the exact order in which I did things.

root@mymachine:~# iwconfig :: no mon interface, wlan0 is managed, not associated, and on channel 6: 2.437GHz
root@mymachine:~# airmon-ng start wlan0 6 :: mon0 created, set on channel 6: 2.437GHz

This is confirmed later by another iwconfig. (on a sidenote, I can change the channel of wlan0, and mon0 stays independent.)

root@mymachine:~# airodump-ng mon0 --channel 6 -w out --output-format pcap :: start a capture on channel 6, write to a file. 

Observation: airodump-ng doesn't display any change in channel, the top left corner is fixed on number 6. However, beacons observed on channels 2 to 11... -> Apparently no selectivity and passing the arguments to both airmon-ng and airodump-ng seem pointless.

Observed with:
CHIPSET Intel 4965 driver iwlwifi
CHIPSET Atheros AR 9271 driver ath9k

Screenshot: screenshot

  • Good question... FYI, in the US 802.11b/g channels 1, 6, and 11 are the only non-overlapping channels Jul 9, 2013 at 10:03
  • @MikePennington thanks for the confirmation.
    – olamotte
    Jul 9, 2013 at 13:35
  • 2
    Are you specifically making the device only send out probes on channel 5? Otherwise, a device will probe on all channels and listen to responses on those channels (less than 100ms). I can only think that would be the reason why you're getting responses on channel 6. (This will happen even if your card is set to use a specific channel, its just how probing works)
    – user275
    Jul 9, 2013 at 14:55
  • @Artanix I understand that the card sends probe requests on every channel, but it does so in turn, and I see them: I am wondering if I may have missed some packets during the capture. I will upload a wireshark screen shot.
    – olamotte
    Jul 10, 2013 at 8:08
  • Quite interesting. The delay between channels isn't that big, but if its definitely happening the way you're suggesting. Then I'd say you've answered your own question as "yes" ;) I don't have a wireless card that works with wireshark yet, so I can't test myself.
    – user275
    Jul 10, 2013 at 8:42

2 Answers 2


What happens is that your wireless device, even when tuned for channel 6 (2437) also have a small probability to receive frames from neighboring channels, such as channel 5 and 7. and even further (with less probability).

This is highly dependent on the wireless interface that you use. The worst radio that I found was an AR9170 based USB adapter, which was able to pick traffic on channel 1 when turned for channel 6. Some other interfaces (e.g. AR9280) do not have this problem, or it is fairly reduced.

PS: AR9271 is not supported by the ath9k driver, but by the ath9k_htc driver. Because this card seems to be the natural successor to AR9170, I am not surprised that you experience the same issue.

  • So it is a selectivity problem: thanks for sharing your experience with this phenomenon.
    – olamotte
    Aug 12, 2013 at 9:55
  • I finally found an explanation in a white paper from 2004 by Devin Akin called "Protection Ripple in ERP 802.11 WLAN". Demonstrated is the ability of an AP on channel 1 to hear beacons from an AP on channel 11. See on page 5 ; cwnp.com/cmsAdmin/uploads/… I am still confused about why the AP would pick up a signal so far away in the frequency band...
    – olamotte
    Mar 22, 2014 at 21:35
  • @olamotte: This is just a frequency shift of 50/2412 = 2%...
    – BatchyX
    Mar 23, 2014 at 9:43
  • @BachyX And I agree with you, these 50MHz are tolerable. My question is about the decision of listening (interpret/process) signals that are not broadcast on the channel the device is set up to operate on. Automated channel selection for the AP to operate on does not need this IMO.
    – olamotte
    Mar 23, 2014 at 20:02

Wireless captures are not the same as a wired capture. In a wired capture, you simply pick your interface and start capturing frames.

With a wireless capture, you select your adapter, but then you also need to choose if you are going to monitor one channel or scan across multiple (or all) channels. There are advantages to both and one needs to understand when to use each.

In your example, since you are capturing on two different channels, either you are using two different capture devices or you are capturing while scanning channels, but I presume you are scanning. What this means is that it stops on one channel for some period of time, captures traffic and then moves onto the next.

So here is how I see this most likely playing out:

  1. Capture device starts monitoring on channel 5.
  2. Client device send probe request on channel 5.
  3. Client device moves to channel 6 and sends probe request.
  4. Capture device moves to channel 6 and starts monitoring.
  5. AP sends probe response on channel 6.

In the end, your capture picks up the probe request on channel 5, but then the probe response on channel 6.

Every wireless capture tool I have used will allow you to select a single channel to monitor. I suspect if you set this to channel 5, you will get the probe requests with no responses. If you set this to channel 6, you will see both the probe requests and the responses.

  • I am going to try to reproduce the setup, and see what happens. I was using airodump-ng with its channel option, could there be a silent error that didnt tell me that. I agree, I should nt see the probe requests on other channels, but since the devices are really closeto each other (few inches) in my office I find it strange. I will double check. For now, from your answer I understand that APS only answer on their assigned channel and don't advertise themselves on nearby channels. Thanks.
    – olamotte
    Jul 11, 2013 at 11:21
  • It could be possible to have the scenario you provide (the channels do overlap and some traffic will be understandable where the sub-carriers overlap), however your capture (if it is on one channel) should not indicate it is capturing on two channels.
    – YLearn
    Jul 11, 2013 at 16:34
  • I provided the airmon-ng parameters I type in... Blaming the software seems a little easy, and I reformulated my initial question: is this behaviour 1) repeatable, could someone with a working device try to observe this 2) specified somewhere in the 802.11 references ? Could not find it my self.
    – olamotte
    Jul 12, 2013 at 6:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.