#
284143 |
|
08-Jun-2015 |
adrian |
Break out the current 802.11 software scan methods into an indirect table.
In order for drivers to provide an alternate set of scan methods, these have to finally use an indirection table and all of the calls in ieee80211_scan.c need to use said table.
For all existing drivers - this is basically a glorified, KBI-breaking functional no-op.
This is also not the final form - too much functionality is currently hiding in ieee80211_scan_sw.c that should be in ieee80211_scan.c. That'll be the target of some follow-up commits.
Note:
* You have to recompile your kernel/drivers after this - the net80211 KBI has changed. * I'm not yet planning on bumping any versioning - I have a few more things to shuffle around.
Tested:
* urtwn(4) - STA mode * Intel 7260 in local repo - overriding the methods and table at attach time has the desired effect (ie, all the methods are called, but nothing is ever performed.)
|
#
282742 |
|
10-May-2015 |
adrian |
Prepare for supporting driver-overridden curchan when submitting scan results.
Right now the scan infrastructure assumes the channel is under net80211 control, and that when receiving beacon frames for scanning, the current channel is indeed what ic_curchan is set to.
But firmware NICs with firmware scan support need more than this - they can do background scans whilst hiding the off-channel behaviour from net80211. Ie, net80211 still thinks everything is associated and on the main channel, but it's getting scan results from all the background traffic.
However sta_add() pays attention to ic_curchan and discards scan results that aren't on the right channel. CCK beacon frames can be decoded from adjacent channels so the receive path and sta_add discard these as appropriate. This is fine for software scanning like for ath(4), but not for firmware NICs. So with those, the whole concept of background firmware scanning won't work without major hacks (eg, overriding ic_curchan before calling the beacon input / scan add.)
As part of my scan overhaul, modify sta_add() and the scan_add() APIs to take an explicit current channel. The normal RX path will set it to ic_curchan so it's a no-op. However, drivers may decide to (eventually!) override the scan method to set the "right" current channel based on what the firmware reports the scan state is.
So for example, iwn, rsu and other NICs will eventually do this:
* driver issues scan start firmware command; * firmware sends a "scan start on channel X" notify; * firmware sends a bunch of beacon RX's as part of the scan results; * .. and the driver will replace scan_add() curchan with channel X, so scan results are correct. * firmware sends a "scan start on channel Y" notify; * firmware sends more beacons... * .. the driver replaces scan_add() curchan with channel Y.
Note:
* Eventually, net80211 should eventually grow the idea of a per-packet current channel. It's possible in various modes (eg WAVE, P2P, etc) that individual frames can come in from different channels and that is under firmware control rather than driver/net80211 control, so we should support that.
|
#
276730 |
|
06-Jan-2015 |
adrian |
Refactor and split out the net80211 software scan engine from the rest of the scan API.
The eventual aim is to have 'ieee80211_scan.c' have the net80211 and driver facing scan API to start, finish and continue doing scanning while 'ieee80211_swscan.c' implements the software scanner that runs the scan task, handles probe request/reply bits, configures the VAP off-channel, changes channel and does the scanning bits.
For NICs that do no scanning at all, the existing code is needed. ath(4) and most of the other NICs (dumb USB ones in particular) do little to no scan offload - it's all done in software.
Some NICs may do single channel at a time scanning; I haven't really checked them out in detail.
iwn(4), the upcoming 7260 driver stuff, the new Qualcomm Atheros 11ac chipsets and the Atheros mobile/USB full-offload chips all have complete scan engines in firmware. We don't have to drive any of it at all - the firmware just needs to be told what to scan, when to scan, how long to scan. It'll take care of going off channel, pausing TX/RX appropriately, sending sleep notification to the AP, sending probe requests and handling probe responses. It'll do passive/active scan itself. It's almost completely transparent to the network stack - all we see are scan notifications when it finishes scanning each channel and beacons/probe responses when it does its thing. Once it's done we get a final notification that the scan is complete, with some scan results in the message. The iwn(4) NICs handle doing active scanning too as an option and will handle waiting appropriately on 5GHz passive channels before active scanning.
There's some more refactoring, tidying up and lock assertions to sprinkle around to tidy this whole thing up before I turn swscan.c into another set of ic methods to override by the driver or alternate scan module. So in theory this is all one big no-op commit. In theory.
Tested:
* iwn(4) 5200, STA mode * ath(4) 6205, STA mode * ath(4) - various NICs, AP mode
|