iwl3945: do not delay hardware scan if it is a direct scan

Browse source

iwl3945 <---> mac80211 <----> wpa_supplicant <---> NetworkManager

When a hardware scan is completed and another scan is requested in less
than two seconds, iwlwifi will not do the second scan and will pass the
error code -EAGAIN back to mac80211 where it quickly dies. The error
code is not passed along to the calling program wpa_supplicant. After a
timeout, wpa_supplicant will just give up but it will not know why the
scan failed. This is a weakness in the design.

I ran into this issue when I was trying to figure out why it takes more
an a minute for NetworkManager to connect after Networking has been
disabled and then re-enabled. I found a good deal of unnecessary work
being done because mac80211 requests authentication when the interface
is not configured, the ANY mode. I created an experimental passive
(NOTANY) mode for mac80211 to eliminate this case. Then NetworkManager
became so fast that I ran into the iwlwifi 2 second delay next scan
issue which we are discussing.

The patch resolves the problem by bypassing the delay if the scan request
is a direct scan. It should do less harm to the hardware.

Signed-off-by: Bill Moss <bmoss@CLEMSON.EDU>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

...

This commit is contained in:

Bill Moss 2008-05-06 11:05:15 +08:00 • committed by John W. Linville

parent 3a1081e84b

commit 15dbf1b7b7

1 changed files with 4 additions and 3 deletions

Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL

Download patch file Download diff file Expand all files Collapse all files

7

drivers/net/wireless/iwlwifi/iwl3945-base.c

View file