path: root/wpa_supplicant/bgscan_simple.c
Commit message (Collapse)AuthorAgeFilesLines
* bgscan: Use monotonic timeJohannes Berg2013-12-241-6/+6
| | | | | | | The bgscan simple and learn algorithms should run regardless of wall clock time jumps, so make them use monotonic time. Signed-hostap: Johannes Berg <johannes.berg@intel.com>
* Remove the GPL notification from files contributed by Jouni MalinenJouni Malinen2012-02-111-8/+2
| | | | | | | Remove the GPL notification text from the files that were initially contributed by myself. Signed-hostap: Jouni Malinen <j@w1.fi>
* bgscan_simple: Refinements to fast-scan backoffPaul Stewart2012-02-051-4/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | These changes account for situations where the CQM threshold might be approximately the same as the currently received signal, and thus CQM events are triggered often due to measurement error/small fluctuations. This results in scanning occurring too frequently. Firstly, inhibit the immediate scan when the short-scan count is at the maximum. This keeps bursts of CQM toggling from causing a torrent of back-to-back scans. This does not inhibit immediate scans if the CQM triggers a second time (if the signal falls lower past the hysteresis). This reduces the scan rate in the worst case (fast-rate toggling high/low CQM events) to the short scan interval. Secondly, change the behavior of the short scan count so it acts like a "leaky bucket". As we perform short-scans, the bucket fills until it reaches a maximal short-scan count, at which we back-off and revert to a long scan interval. The short scan count decreases by one (emptying the bucket) every time we complete a long scan interval without a low-RSSI CQM event. This reduces the impact of medium-rate toggling of high/low CQM events, reducing the number of short-interval scans that occur before returning to a long-interval if the system was recently doing short scans.
* bgscan_simple: Reschedule first fast scanPaul Stewart2011-03-311-0/+12
| | | | | | | | | If the scan interval switches to the short interval soon after a scan, bgscan_simple should not immediately scan again. However, it should also make sure that the next scan occurs no later than the new, short scan interval. Signed-off-by: Paul Stewart <pstew@google.com>
* bgscan_simple: Time out short scan intervalPaul Stewart2011-03-311-1/+18
| | | | | | | | | | We gain diminishing returns by the short scan interval. The short scan interval is used to hunt for a better AP if the RSSI of the current AP drops. However, if we never roam, and the AP continues to have low RSSI, at some point we should give up and return to the slow background scan rate, otherwise we waste a lot of power. Signed-off-by: Paul Stewart <pstew@google.com>
* bgscan-simple: Poll for signal in initPaul Stewart2011-03-311-0/+9
| | | | | | | | It is not guaranteed that we will get a CQM signal shortly after setting up monitoring. In order to establish the correct initial background scanning rate, poll directly for the signal strength. Signed-off-by: Paul Stewart
* bgscan: Add new channel condition parameters to signal change eventsPaul Stewart2010-10-121-2/+6
| | | | | bgscan modules can potentially get a richer feel for the channel condition and make better choices about scan/no-scan and roam/no-roam.
* bgscan simple: Skip immediate scan on initial signal eventJouni Malinen2010-08-271-14/+25
| | | | | | | The driver is likely to indicate an immediate signal event when the threshold value is configured. Since we do this immediately after association, there is not much point in requesting a new scan to be started based on this event.
* Add current signal strength into signal quality change eventsJouni Malinen2010-08-271-2/+3
* bgscan: Provide scan results to the notify_scan handlerJouni Malinen2010-07-101-1/+2
* bgscan: Add signal strength change eventsJouni Malinen2010-03-281-9/+97
| | | | | | | | | | | | | This allows bgscan modules to use more information to decide on when to perform background scans. bgscan_simple can now change between short and long background scan intervals based on signal strength and in addition, it can trigger immediate scans when the signal strength is detected to be dropping. bgscan_simple takes following parameters now: short interval:signal strength threshold:long interval For example: bgscan="simple:30:-45:300"
* Move wpa_supplicant specific scan code away from src/driversJouni Malinen2010-01-031-0/+1
| | | | | | This fits better in wpa_supplicant/scan.c. Couple of remaining scan_helpers.c functions are currently used in driver wrappers, but they can likely be removed in the future.
* Add preliminary background scan and roaming module designJouni Malinen2009-09-141-0/+130
This allows background scanning and roaming decisions to be contained in a single place based on a defined set of notification events which will hopefully make it easier to experiment with roaming improvements. In addition, this allows multiple intra-ESS roaming policies to be used (each network configuration block can configure its own bgscan module). The beacon loss and signal strength notifications are implemented for the bgscan API, but the actual events are not yet available from the driver. The included sample bgscan module ("simple") is an example of what can be done with the new bgscan mechanism. It requests periodic background scans when the device remains associated with an ESS and has couple of notes on what a more advanced bgscan module could do to optimize background scanning and roaming. The periodic scans will cause the scan result handler to pick a better AP if one becomes available. This bgscan module can be taken into use by adding bgscan="simple" (or bgscan="simple:<bgscan interval in seconds>") into the network configuration block.