19

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.)

EDIT 1:

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.

EDIT 2:

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

Serge Stroobandt
  • 103
  • 6
olamotte
  • 293
  • 2
  • 6
  • Good question... FYI, in the US 802.11b/g channels 1, 6, and 11 are the only non-overlapping channels – Mike Pennington Jul 09 '13 at 10:03
  • @MikePennington thanks for the confirmation. – olamotte Jul 09 '13 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) –  Jul 09 '13 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 '13 at 08: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. –  Jul 10 '13 at 08:42
  • @Artanix I could see an advantage in answering requests on multiple channels, only if the AP selection process is -first come, first served-, and connecting the card to the first satisfying network, without caring about the nearby unscanned channels. Doesn't sound great though, and it is not what my card is doing. I noticed this behaviour only with one of my APS, a Netgear WNR1000v2 with firmware v1.1.2.58 – olamotte Jul 10 '13 at 08:54
  • @olamotte, I played with airodump-ng with three different adapters, and on none of them when I specify a channel do I see anything on any other channel than the one specified. Can you verify it isn't scanning when you run airodup-ng (top left corner should indicate current channel)? – YLearn Jul 14 '13 at 04:50
  • @YLearn It is fixed on channel 6. Let me get to work and I will make a screenshot. I precise the channel when calling airodump, and it is not looping on all the channels. Are there are any networks on other channels in your surroundings ;) ? – olamotte Jul 15 '13 at 07:52
  • @olamotte, yes there are other networks, both on the same channel and others. I tested in three locations (a quiet residential, a busy residential and an EDU with research networks on a number of channels) and none of them showed any beacons other than the channel specified when I ran airodump-ng. – YLearn Jul 15 '13 at 16:37

2 Answers2

7

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.

BatchyX
  • 841
  • 4
  • 6
  • So it is a selectivity problem: thanks for sharing your experience with this phenomenon. – olamotte Aug 12 '13 at 09: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 ; http://www.cwnp.com/cmsAdmin/uploads/protection_ripple_in_erp_802-11_wlans.pdf I am still confused about why the AP would pick up a signal so far away in the frequency band... – olamotte Mar 22 '14 at 21:35
  • @olamotte: This is just a frequency shift of 50/2412 = 2%... – BatchyX Mar 23 '14 at 09: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 '14 at 20:02
6

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.

YLearn
  • 27,141
  • 5
  • 59
  • 128
  • 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 '13 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 '13 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 '13 at 06:01