mirror of
https://github.com/freebsd/freebsd-src
synced 2024-10-06 00:20:29 +00:00
2808a02bf4
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. |
||
|---|---|---|
| .. | ||
| _ieee80211.h | ||
| ieee80211.c | ||
| ieee80211.h | ||
| ieee80211_acl.c | ||
| ieee80211_action.c | ||
| ieee80211_action.h | ||
| ieee80211_adhoc.c | ||
| ieee80211_adhoc.h | ||
| ieee80211_ageq.c | ||
| ieee80211_ageq.h | ||
| ieee80211_alq.c | ||
| ieee80211_alq.h | ||
| ieee80211_amrr.c | ||
| ieee80211_amrr.h | ||
| ieee80211_crypto.c | ||
| ieee80211_crypto.h | ||
| ieee80211_crypto_ccmp.c | ||
| ieee80211_crypto_none.c | ||
| ieee80211_crypto_tkip.c | ||
| ieee80211_crypto_wep.c | ||
| ieee80211_ddb.c | ||
| ieee80211_dfs.c | ||
| ieee80211_dfs.h | ||
| ieee80211_freebsd.c | ||
| ieee80211_freebsd.h | ||
| ieee80211_hostap.c | ||
| ieee80211_hostap.h | ||
| ieee80211_ht.c | ||
| ieee80211_ht.h | ||
| ieee80211_hwmp.c | ||
| ieee80211_input.c | ||
| ieee80211_input.h | ||
| ieee80211_ioctl.c | ||
| ieee80211_ioctl.h | ||
| ieee80211_mesh.c | ||
| ieee80211_mesh.h | ||
| ieee80211_monitor.c | ||
| ieee80211_monitor.h | ||
| ieee80211_node.c | ||
| ieee80211_node.h | ||
| ieee80211_output.c | ||
| ieee80211_phy.c | ||
| ieee80211_phy.h | ||
| ieee80211_power.c | ||
| ieee80211_power.h | ||
| ieee80211_proto.c | ||
| ieee80211_proto.h | ||
| ieee80211_radiotap.c | ||
| ieee80211_radiotap.h | ||
| ieee80211_ratectl.c | ||
| ieee80211_ratectl.h | ||
| ieee80211_ratectl_none.c | ||
| ieee80211_regdomain.c | ||
| ieee80211_regdomain.h | ||
| ieee80211_rssadapt.c | ||
| ieee80211_rssadapt.h | ||
| ieee80211_scan.c | ||
| ieee80211_scan.h | ||
| ieee80211_scan_sta.c | ||
| ieee80211_scan_sw.c | ||
| ieee80211_scan_sw.h | ||
| ieee80211_sta.c | ||
| ieee80211_sta.h | ||
| ieee80211_superg.c | ||
| ieee80211_superg.h | ||
| ieee80211_tdma.c | ||
| ieee80211_tdma.h | ||
| ieee80211_var.h | ||
| ieee80211_wds.c | ||
| ieee80211_wds.h | ||
| ieee80211_xauth.c | ||