Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #992 (new defect)

Opened 16 years ago

Last modified 16 years ago

Active scanning behavior seems to be not in accordance with IEEE802.11

Reported by: Assigned to:
Priority: minor Milestone:
Component: madwifi: 802.11 stack Version: trunk
Keywords: Cc:
Patch is attached: 0 Pending:

Description (Last modified by mrenzmann)

Please correct me if I'm wrong, but it seems that both the stable version 0.9.2 and trunk implement active scanning not in accordance with IEEE802.11 standard.

Let me begin with citing Section "Active scanning procedure" of the standard:

Upon receipt of the MLME-SCAN.request with ScanType indicating an active scan, a STA shall use the following procedure: For each channel to be scanned,

a) Wait until the ProbeDelay time has expired or a PHYRxStart.indication has been received;

b) Perform the Basic Access procedure as defined in;

c) Send a probe with the broadcast destination, SSID, and broadcast BSSID;

d) Clear and start a ProbeTimer;

e) If PHYCCA.indication (busy) has not been detected before the ProbeTimer reaches MinChannelTime, then clear NAV and scan the next channel, else when ProbeTimer reaches MaxChannelTime, process all received probe responses;

f) Clear NAV and scan the next channel.

When all channels in the ChannelList have been scanned, the MLME shall issue an MLME-Scan.confirm with the BSSDescriptionSet containing all of the information gathered during the scan.

My interpretation of the written above would be the following:

  1. Wait until we can send out a probe response frame.
  2. Send out the probe response frame and start ProbeTimer.
  3. If nothing has been received on the channel for the MinChannelTime interval, we conclude that there is nobody on the channel and we can switch to the next channel.
  4. Otherwise, we have to wait the entire interval MaxChannelTime while collecting the incoming probe responses.

The interpretation similar to mine can also be found at

Now, let us look at how the active scanning behavior is implemented in madwifi. The relevant file is ieee80211_scan.c. Its two functions, scan_next and ieee80211_add_scan, are relevant in our case. The former schedules the scanning of a single channel, whereas the latter processes incoming probe responses and beacons. The scan_next gets invoked on the expiration of SCAN_PRIVATE(ss)->ss_scan_timer, which is set by calling mod_timer(&SCAN_PRIVATE(ss)->ss_scan_timer, jiffies+<some_timeout>).

My intuition suggests that the following varible mapping is used w.r.t to IEEE802.11:

  1. SCAN_PRIVATE(ss)->ss_chanmindwell corresponds with MinChannelTime
  2. SCAN_PRIVATE(ss)->ss_chanmaxdwell corresponds with MaxChannelTime

Now if we take a look at scan_next, we can see that until scan is completed (due to expiration of the time allocated for scan, due to canceling, due to looking through all the channels), the next invocation for scan_next for the the next channel is scheduled to happen at jiffies+maxdwelltime. If we take a look the ieee80211_add_scan function, we'll see that the next channel is switched to as soon as at least one probe response or beacon is received after the scanning algorithm was listening for more then the SCAN_PRIVATE(ss)->ss_chanmindwell time.

In fact, this behavior seems to be the opposite to what the standard says, that is, stay on the same channel for MaxChannelTime, if something has been received during the MinChannelTime interval. Moreover, the standard does not even require that probe responses must be received during this MinChannelTime interval. It is sufficient to detect that there was some signal in the channel. Further, the active scanning procedure does not say anything about processing beacons during the active scan. I would assume that accounting for beacons will not violate the standard.

Now the question is (1) if my observations are correct, and (2) if they are, does the active scanning behavior require modification in accordance with the procedure recommended by the standard?

Change History

11/01/06 14:51:59 changed by mrenzmann

  • description changed.