Currently then dwell times for each channel in scans is set to an overly
long value, and excessive number of probe-requests are transmitted on each
channel (for active scans.)
Based on testing, comparable results can be received with smaller dwell-time,
and, with fever probe-requests - in fact, reducing the number of probe-requests
to 2 seems to increase the number of found results.
Configure more optimal values for per channel dwell times. Comparison for the
different scan configurations (in my current office environment):
dwell-time 60000 3x probe-req == ~60 results
40000 3x probe-req == ~50 results
30000 3x probe-req == ~40 results
dwell-time 60000 2x probe-req == ~70 results
40000 2x probe-req == ~60 results
30000 2x probe-req == ~58 results
The above are results for a cumulative 3 scan run. For individual scans, the
number of results drop slightly more.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Currently, the driver does not handle a failing hardware command to scan in
any way - effectively, the scan machine will jam until the driver is shut down,
and future scan requests will just return -EBUSY to user space, resulting in
a type of busy-loop. The same problem occurs if the firmware fails to deliver
the scan completion event - add timeout for this.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Do this so the interface removal can be triggered from an upcoming hardware
failure recovery mechanism.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
The current scan implementation can jam, if the scan request ends up
containing no work. This can especially happen if there is a scan request
with only 11a band channels for HW that does not support 11a.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Instead of hardcoding 11a support, enable/disable driver support based on
the dual-mode-select parameter in the nvs-file general paramters.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
When we get no SSIDs in the scan request, we should force a passive scan in
all channels. This patch adds code to force the passive scan flag to be set
in that case.
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Reviewed-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
In the scan state machine, the wl1271_mutex is unlocked first then relocked,
and then the scan state variables are modified.
This makes it possible for ieee80211_scan_complete to be called twice in some
scenarios, as the scan completion event from the firmware may be processed
while the mutex is unlocked.
To fix the issue, move the ieee80211_scan_complete call last in the function.
This is generally safer, but there still may be issues is functions calling
the scan state machine rely on states checked before the unlocking of the
global mutex.
(forward ported from 2.6.32 -- this is not strictly needed anymore, because
the mutex doesn't need to be unlocked anymore, but I'm applying this change
anyway, so that the call to ieee80211_scan_complete is in the same place)
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Saravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
With the scan callback now being callable from
any context, these unlocks/locks can go away.
This makes the code easier to understand, since
callers of these functions must no longer be
aware that the mutex may be dropped.
As Stanislaw is working on iwlwifi scanning, I
didn't change it to take advantage of the new
mac80211 semantics.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
These changes may be slightly safer in some instances.
There are other kzalloc calls with a multiply, but those
calls are typically "small fixed #" * sizeof(some pointer)"
and those are not converted.
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We were always using the max transmit power when scanning. Now we use the
values passed to the driver by the mac80211 stack, so that we comply with
regulations.
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Reviewed-by: Saravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch is a complete rewrite of the scanning code. It now includes a
state machine to scan all four possible sets of channels independently:
2.4GHz active, 2.4GHz passive, 5GHz active and 5GHz passive. The wl1271
firmware doesn't allow these sets to be mixed, so up to several scan commands
have to be issued. This patch also allows scanning more than 24 channels per
set, by breaking the sets into smaller parts if needed (the firmware can scan
a maximum of 24 channels at a time).
Previously, the scanning code was erroneously scanning all channels possible
actively, not complying with the CRDA values. This is also fixed with this
patch.
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Reviewed-by: Saravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The scanning code is going to get a bit more complex, with proper support for
active/passive scans together with 2.4GHz and 5GHz. In the future, also a
new type of scan (periodic scan) will be added. When all this is
implemented, the code is going to be much more complex, so we'd better
separate it into a separate file.
This patch doesn't have any impact on functionality.
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Reviewed-by: Saravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
