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 #646 (closed defect: worksforme)

Opened 16 years ago

Last modified 15 years ago

scan results delayed to wpa_supplicant

Reported by: Assigned to:
Priority: major Milestone: version 0.9.x - progressive release candidate phase
Component: madwifi: 802.11 stack Version: trunk
Keywords: Cc:
Patch is attached: 0 Pending:


I just started working with madwifi a few weeks ago... my environment is as follows:

* AMD Geode processor running on a Pepper prototype system
* Distribution: Pepper / FC4-based
* Kernel: 2.6.12 w/AMD Geode specific patches 
* Wireless Extensions v17
* WiFi Hw: mini-PCI b/g card using an AR2413 chip ( PCI Device ID: 0x001a )

We use a modified version of wpa_supplicant 0.4.7 and control scanning and association by dynamically creating and enabling networks via wpa_supplicant's control interface.

Most things worked great with r1500, however when I moved up to r1590, when wpa_supplicant scans ( via a SIOCSIWSCAN ), it times out after ~30 seconds. After the timeout, the code tries to retrieve the scan results anyways and succeeds, however 30 seconds is a long time to wait. Note - wpa_supplicant was built against the r1590 of madwifi.

When this same scenario is run with r1500, the scan results are returned to wpa_supplicant within ~2 seconds.

One more note, this behavior only shows up with wpa_supplicant. If I disable it on boot, and then run 'iwlist <intf> scan', results appear immediately for both r1500 and r1590.

Change History

05/24/06 03:57:03 changed by kelmo

  • milestone set to version 0.9.0 - move to new codebase.

This is closely related to #275 (the patch there works around the greater problem, and would also be on topic for the discussion in #572.

05/24/06 03:57:18 changed by kelmo

  • milestone changed from version 0.9.0 - move to new codebase to version 0.9.x - progressive release candidate phase.

05/24/06 03:58:31 changed by kelmo

  • summary changed from r1590 - scan results delayed to wpa_supplicant v0.4.7 to scan results delayed to wpa_supplicant.

Furthermore, i think the problem has always been there, so I'll change the topic slightly.

05/25/06 22:09:40 changed by

I just ran thru the snapshots starting at r1500 (which works) and found that this problem was introduced in build r1527. I haven't dug into the source yet. That's my next step.

As for the related tickets, #275 seems to focus on two issues: (1) scans with an SSID specified and (2) a race between multiple scan requests.

In the case I'm seeing, wpa_suppl initiates a BROADCAST scan ( ie. no SSID specified ) and a second scan request is not made for ~10 seconds. Pre-r1527, a wireless event is generated by madwifi-ng ~2-3 seconds after the BROADCAST scan is initiated via the SIOCSIWSCAN ioctl ( made by wpa_suppl's madwifi driver module ). When r1527 and greater snapshots are run, the wireless event doesn't seem to get generated anymore, hence the 30 second timeout in wpa_suppl eventually fires and the scan results are retrieved.

I also looked at #572 and don't see any relation to this problem as the mode of our interface is set to 'Managed' at boot time and is never changed.

05/26/06 00:23:50 changed by anonymous

I've tracked down the code change that introduces this behavior. In the file ieee80211_proto.c, function ieee80211_init() the following change was made ( diff -c between r1526 and r1527 ):

<                 if (forcescan)
>                 if (vap->iv_state != IEEE80211_S_RUN || forcescan)
<                 else if (vap->iv_state == IEEE80211_S_RUN)
>                 else

What I don't understand is why this code is executing. It's protected by a check for IEEE80211_ROAMING_MANUAL which causes the above code to be skipped. I checked wpa_suppl's madwifi driver module and it initialization code does set roaming to manual. Guess I need to confirm that it it *is* actually being and set and doesn't get inadvertently reset somewhere else...

05/26/06 02:15:18 changed by

OK, I think I've got it... basically what happens is that ieee80211_init() gets called automatically by ieee80211_open(). It's a chicken and egg thing... wpa_suppl has to open a socket to the driver in order to set the roaming mode, which in turn causes the state to get set to SCAN. Why this prevents the scan event from being fired, I'm not sure, but I have verified that if the state is not set to SCAN here, the event is fired.

The pre-r1527 code would only set the state to SCAN if forcestate was set.

For now a workaround for those running wpa_suppl would be to hard-code the driver ic_roaming setting to IEEE80211_ROAMING_MANUAL. I will try and test this tomorrow and post my results.

05/29/06 01:04:35 changed by anonymous

  • cc set to

06/03/06 02:20:25 changed by

In addition to hard-coding roaming to MANUAL, I also found that the function ieee80211_scan_attach() always sets roaming to AUTO and never saves it's previous value.

I modified this function to only set roaming to AUTO if the mode wasn't already set to MANUAL.

This patch resolves the scan delay seen by wpa_supplicant, however it has the bad side-effect of preventing manual association from working via iwconfig ( because the roaming mode is hard-coded to MANUAL).

Perhaps the fix should be made to the roaming ioctl code? If the roaming mode is set to manual, then reset the state machine to it's initial state?

Anwyays, that's all for now...

07/17/07 14:37:19 changed by mtaylor

  • status changed from new to closed.
  • resolution set to worksforme.

This ticket has not been updated in over six months and is being marked as "works for me" automatically.

If the ticket is still applies to the head revision of trunk, please re-open the ticket and provide any additional details needed and progress on the problem to date. Thanks.