- Pass scan state and additional internal flags as a parameters.
- Add locked version.
Tested with:
* Intel 3945BG, STA mode.
* RTL8188EU, STA mode.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5148
transmitted
- Use M_TXCB mechanism to report about null data frame transmission.
- Increase timeout from 1 to 10 ms (the previous one may be not enough
for non-empty queue).
Tested with:
* Intel 3945BG, STA mode.
* RTL8188CUS, STA mode.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5147
scan_curchan_task() functions)
(This part should fix the problem, described in
https://lists.freebsd.org/pipermail/freebsd-wireless/2016-January/006420.html)
- Rename ss_scan_task into ss_scan_start (better describes it's
current purpose)
- Utilize taskqueue_*_timeout() functions instead of current mechanism:
* reschedule scan_curchan_task() via taskqueue_enqueue_timeout()
for every 'maxdwell' msecs (will replace infinite loop + sleeping
for 'maxdwell' period via cv_wait());
* rerun the task immediately when an external event occurs
(instead of waking it up via cv_signal())
Also, use mtx_sleep() to wait for null frame transmission
(allows to drop conditional variable).
Tested with:
* Intel 3945BG, STA mode;
* RTL8188EU, STA mode.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5145
we're assuming hz=1000 and not gracefully handling when it isn't.
The math involved will return 0 for hz < 1000, which it is on some
platforms and on DragonflyBSD.
This doesn't fix it, it:
* converts one manual use over to use the macro, and
* comments where it needs some thought/fixing.
I'll think about this a bit more before fixing it.
Submitted by: imre@vdsz.com
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.)
DragonflyBSD uses the FreeBSD wireless stack and drivers. Their malloc()
API is named differently, so they don't have userland/kernel symbol
clashes like we do (think libuinet.)
So, to make it easier for them and to port to other BSDs/other operating
systems, start hiding the malloc specific bits behind defines in
ieee80211_freebsd.h.
DragonflyBSD can now put these portability defines in their local
ieee80211_dragonflybsd.h.
This should be a great big no-op for everyone running wifi.
TODO:
* kill M_WAITOK - some platforms just don't want you to use it
* .. and/or handle it returning NULL rather than waiting forever.
* MALLOC_DEFINE() ?
* Migrate the well-known malloc names (eg M_TEMP) to net80211
namespace defines.
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.
It turns out that ieee80211_start_scan_locked() is only ever called by
the swscan code and it won't likely be required by firmware scanning
implementations.
So, don't bother keeping it in ieee80211_scan.c and it likely won't
become an API call.
Tested:
* Intel 5100, STA mode
* AR5416, STA mode
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
