diff options
author | Bill Moss <bmoss@CLEMSON.EDU> | 2008-05-06 03:05:15 (GMT) |
---|---|---|
committer | John W. Linville <linville@tuxdriver.com> | 2008-05-14 20:29:48 (GMT) |
commit | 15dbf1b7b7b6ba6e5159dde60e111f617b2c54ea (patch) | |
tree | 0f34c2761940f2fab9a720dff4d33730417ab4b0 /drivers/base | |
parent | 3a1081e84b0008de8171a95f2c0fff8489af4300 (diff) | |
download | linux-fsl-qoriq-15dbf1b7b7b6ba6e5159dde60e111f617b2c54ea.tar.xz |
iwl3945: do not delay hardware scan if it is a direct scan
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>
Diffstat (limited to 'drivers/base')
0 files changed, 0 insertions, 0 deletions