#
685dc743 |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
4d846d26 |
|
10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
|
#
fb5a5026 |
|
09-Apr-2022 |
Gordon Bergling <gbe@FreeBSD.org> |
net80211(4): Fix a typo in a source code comment - s/is is/is/ MFC after: 3 days
|
#
662c1305 |
|
01-Sep-2020 |
Mateusz Guzik <mjg@FreeBSD.org> |
net: clean up empty lines in .c and .h files
|
#
f1481c8d |
|
30-Jun-2020 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] Migrate HT/legacy protection mode and preamble calculation to per-VAP flags The later firmware devices (including iwn!) support multiple configuration contexts for a lot of things, leaving it up to the firmware to decide which channel and vap is active. This allows for things like off-channel p2p sta/ap operation and other weird things. However, net80211 is still focused on a "net80211 drives all" when it comes to driving the NIC, and as part of this history a lot of these options are global and not per-VAP. This is fine when net80211 drives things and all VAPs share a single channel - these parameters importantly really reflect the state of the channel! - but it will increasingly be not fine when we start supporting more weird configurations and more recent NICs. Yeah, recent like iwn/iwm. Anyway - so, migrate all of the HT protection, legacy protection and preamble stuff to be per-VAP. The global flags are still there; they're now calculated in a deferred taskqueue that mirrors the old behaviour. Firmware based drivers which have per-VAP configuration of these parameters can now just listen to the per-VAP options. What do I mean by per-channel? Well, the above configuration parameters really are about interoperation with other devices on the same channel. Eg, HT protection mode will flip to legacy/mixed if it hears ANY BSS that supports non-HT stations or indicates it has non-HT stations associated. So, these flags really should be per-channel rather than per-VAP, and then for things like "do i need short preamble or long preamble?" turn into a "do I need it for this current operating channel". Then any VAP using it can query the channel that it's on, reflecting the real required state. This patch does none of the above paragraph just yet. I'm also cheating a bit - I'm currently not using separate taskqueues for the beacon updates and the per-VAP configuration updates. I can always further split it later if I need to but I didn't think it was SUPER important here. So: * Create vap taskqueue entries for ERP/protection, HT protection and short/long preamble; * Migrate the HT station count, short/long slot station count, etc - into per-VAP variables rather than global; * Fix a bug with my WME work from a while ago which made it per-VAP - do the WME beacon update /after/ the WME update taskqueue runs, not before; * Any time the HT protmode configuration changes or the ERP protection mode config changes - schedule the task, which will call the driver without the net80211 lock held and all correctly serialised; * Use the global flags for beacon IEs and VAP flags for probe responses and other IE situations. The primary consumer of this is ath10k. iwn could use it when sending RXON, but we don't support IBSS or AP modes on it yet, and I'm not yet sure whether it's required in STA mode (ie whether the firmware parses beacons to change protection mode or whether we need to.) Tested: * AR9280, STA/AP * AR9380, DWDS STA+STA/AP * ath10k work, STA/AP * Intel 6235, STA * Various rtwn / run NICs, DWDS STA and STA configurations
|
#
fe267a55 |
|
27-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
sys: general adoption of SPDX licensing ID tags. Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. No functional change intended.
|
#
b8e29e06 |
|
29-Mar-2016 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] migrate the time_* macros to ieee80211_* namespace. It turns out that these will clash very annoyingly with the linux macros in the linuxkpi layer, so let the wookie^Wlinux win. The only user that I can find is ath(4), so fix it there too.
|
#
8ec07310 |
|
01-Feb-2016 |
Gleb Smirnoff <glebius@FreeBSD.org> |
These files were getting sys/malloc.h and vm/uma.h with header pollution via sys/mbuf.h
|
#
d3a4ade3 |
|
11-Oct-2015 |
Adrian Chadd <adrian@FreeBSD.org> |
net80211: free node reference in the ieee80211_parent_xmitpkt() when error happened. Move error handling into ieee80211_parent_xmitpkt() instead of spreading it between functions. Submitted by: <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3772
|
#
7a79cebf |
|
27-Aug-2015 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
|
#
ba2c1fbc |
|
07-Aug-2015 |
Adrian Chadd <adrian@FreeBSD.org> |
Revert the wifi ifnet changes until things are more baked and tested. * 286410 * 286413 * 286416 The initial commit broke a variety of debug and features that aren't in the GENERIC kernels but are enabled in other platforms.
|
#
79d2c5e8 |
|
07-Aug-2015 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Details here: https://wiki.freebsd.org/projects/ifnet/net80211 Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances of problems are low. The wtap wasn't compilable even before this change. But the ndis driver is complex, and it is likely to be broken with this commit. Help with testing and debugging it is appreciated. Differential Revision: D2655, D2740 Sponsored by: Nginx, Inc. Sponsored by: Netflix
|
#
b9b53389 |
|
25-May-2015 |
Adrian Chadd <adrian@FreeBSD.org> |
Convert malloc/free back to #define's, as part of OS portability work. 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.
|
#
1de34f86 |
|
20-Dec-2014 |
Adrian Chadd <adrian@FreeBSD.org> |
Update ieee80211_sta_tim_notify() to do double duty - handle STA sleep to awake transition as well as handle waking up a VAP in STA powersave mode if it's in bgscan. This was a reasonably hairy bug to try and figure out and it became more obvious because of stuff I've done. Specifically: * a NIC would go into bgscan mode - either because of a bgscan timer or wpa_supplicant asked it to; * the AP would indicate there's traffic for the STA by setting the TIM bitmap bit for it; * mindwell would be met during scan, so it'd wake up and break out of the scan loop in scan_task(), but * because the scan wasn't completed, it wouldn't bring the VAP out of STA mode powersave (so it wouldn't tell the AP about it and it would block VAP TX); * .. but because we kept seeing the TIM bit set, ic->ic_lastdata was being constantly updated, and .. * bgscancont() would thus never say "yes we can continue a bgscan" so the bgscan would hang and never make progress. Now, I do see this particular state occur on iwn(4) - /however/ - this NIC has the firmware call ieee80211_scan_next() once the firmware scan for that channel has completed. This has the effect of moving the scan along to the next channel. I do see the debug that I'm adding where we see a beacon with a TIM bit set whilst we're in bgscan, so the condition about waking up to receive traffic is triggering. It just won't cause a hang. For other NICs - all of the USB ones and at least ath(4) - ieee80211_scan_next() / ieee80211_scan_done() isn't called. So it relies upon the mindwell timer, the beacon receive and the beacon / probe response -> ieee80211_add_scan() to move along the scan state. In the above case, mindwell triggered, there's no beacons triggering the scan_add code to move things along, and we weren't waking things up when seeing the TIM set for us. So it just hung until the interface was dropped. So, the short-term fix here is to do what the comment in scan_task() says - if we are in bgscan mode and we see our TIM bit set, just wake up the VAP. If it's already awake then it's a nop. If we're awake then we transition to awake and handle the traffic. Once there's no TX or RX traffic going on, ic->ic_lastdata won't be updated anymore and bgscancont() will continue. This was triggered more often after my initial SLEEP state handling for software sleep states - because now I update ic->ic_lastdata upon seeing a TIM bit set, not just the RX of the subsequent traffic. That's needed so the thing doesn't ping-pong up and down between seeing the TIM bit set, sending the "I'm awake" NULL data frame, and starting to receive data from the AP. I'd like to subsequently split ic_lastdata into two - one for TX and one for RX - so it becomes easier to use the correct one (or both!) when making decisions like whether to scan, go to sleep, etc. I'd appreciate this getting some further testing. Tested: * rsu(4), STA mode, bgscan on * iwn(4), STA mode, bgscan on
|
#
902840a5 |
|
23-Apr-2014 |
Adrian Chadd <adrian@FreeBSD.org> |
Begin fleshing out support for net80211 provided (legacy) sleep management. This transitions the VAP in and out of SLEEP state based on: * whether there's been an active transmission in the last (hardcoded) 500ms; * whether the TIM from the AP indicates there is data available. It uses the beacon reception to trigger the active traffic check. This way there's no further timer running to wake up the CPU from its own sleep states. Right now the VAP isn't woken up for multicast traffic - mostly because the only NIC I plan on doing this for right will auto wakeup and stay awake for multicast traffic indicated in the TIM. So I don't have to manually keep the hardware awake. This doesn't do anything if the NIC doesn't advertise it implements the new SWSLEEP capability AND if the VAP doesn't have powersave enabled. It also doesn't do much with ath(4) as it doesn't currently implement the SLEEP state. Tested: * AR5416, STA mode (with local ath(4) changes)
|
#
76039bc8 |
|
26-Oct-2013 |
Gleb Smirnoff <glebius@FreeBSD.org> |
The r48589 promised to remove implicit inclusion of if_var.h soon. Prepare to this event, adding if_var.h to files that do need it. Also, include all includes that now are included due to implicit pollution via if_var.h Sponsored by: Netflix Sponsored by: Nginx, Inc.
|
#
57b5fc5f |
|
12-Aug-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Blank m_nextpkt before passing it up.
|
#
4bd57e10 |
|
11-Aug-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
When flushing packets from the powersave queue, make sure that m_nextpkt is NULL before passing it up to the parent transmit method.
|
#
e7495198 |
|
07-Aug-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Convert net80211 over to using if_transmit for the dispatch from the upper layer(s). This eliminates the if_snd queue from net80211. Yay! This unfortunately has a few side effects: * It breaks ALTQ to net80211 for now - sorry everyone, but fixing parallelism and eliminating the if_snd queue is more important than supporting this broken traffic scheduling model. :-) * There's no VAP and IC flush methods just yet - I think I'll add some NULL methods for now just as placeholders. * It reduces throughput a little because now net80211 will drop packets rather than buffer them if the driver doesn't do its own buffering. This will be addressed in the future as I implement per-node software queues. Tested: * ath(4) and iwn(4) in STA operation
|
#
5cda6006 |
|
08-Mar-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Bring over my initial work from the net80211 TX locking branch. This patchset implements a new TX lock, covering both the per-VAP (and thus per-node) TX locking and the serialisation through to the underlying physical device. This implements the hard requirement that frames to the underlying physical device are scheduled to the underlying device in the same order that they are processed at the VAP layer. This includes adding extra encapsulation state (such as sequence numbers and CCMP IV numbers.) Any order mismatch here will result in dropped packets at the receiver. There are multiple transmit contexts from the upper protocol layers as well as the "raw" interface via the management and BPF transmit paths. All of these need to be correctly serialised or bad behaviour will result under load. The specifics: * add a new TX IC lock - it will eventually just be used for serialisation to the underlying physical device but for now it's used for both the VAP encapsulation/serialisation and the physical device dispatch. This lock is specifically non-recursive. * Methodize the parent transmit, vap transmit and ic_raw_xmit function pointers; use lock assertions in the parent/vap transmit routines. * Add a lock assertion in ieee80211_encap() - the TX lock must be held here to guarantee sensible behaviour. * Refactor out the packet sending code from ieee80211_start() - now ieee80211_start() is just a loop over the ifnet queue and it dispatches each VAP packet send through ieee80211_start_pkt(). Yes, I will likely rename ieee80211_start_pkt() to something that better reflects its status as a VAP packet transmit path. More on that later. * Add locking around the management and BAR TX sending - to ensure that encapsulation and TX are done hand-in-hand. * Add locking in the mesh code - again, to ensure that encapsulation and mesh transmit are done hand-in-hand. * Add locking around the power save queue and ageq handling, when dispatching to the parent interface. * Add locking around the WDS handoff. * Add a note in the mesh dispatch code that the TX path needs to be re-thought-out - right now it's doing a direct parent device transmit rather than going via the vap layer. It may "work", but it's likely incorrect (as it bypasses any possible per-node power save and aggregation handling.) Why not a per-VAP or per-node lock? Because in order to ensure per-VAP ordering, we'd have to hold the VAP lock across parent->if_transmit(). There are a few problems with this: * There's some state being setup during each driver transmit - specifically, the encryption encap / CCMP IV setup. That should eventually be dragged back into the encapsulation phase but for now it lives in the driver TX path. This should be locked. * Two drivers (ath, iwn) re-use the node->ni_txseqs array in order to allocate sequence numbers when doing transmit aggregation. This should also be locked. * Drivers may have multiple frames queued already - so when one calls if_transmit(), it may end up dispatching multiple frames for different VAPs/nodes, each needing a different lock when handling that particular end destination. So to be "correct" locking-wise, we'd end up needing to grab a VAP or node lock inside the driver TX path when setting up crypto / AMPDU sequence numbers, and we may already _have_ a TX lock held - mostly for the same destination vap/node, but sometimes it'll be for others. That could lead to LORs and thus deadlocks. So for now, I'm sticking with an IC TX lock. It has the advantage of papering over the above and it also has the added advantage that I can assert that it's being held when doing a parent device transmit. I'll look at splitting the locks out a bit more later on. General outstanding net80211 TX path issues / TODO: * Look into separating out the VAP serialisation and the IC handoff. It's going to be tricky as parent->if_transmit() doesn't give me the opportunity to split queuing from driver dispatch. See above. * Work with monthadar to fix up the mesh transmit path so it doesn't go via the parent interface when retransmitting frames. * Push the encryption handling back into the driver, if it's at all architectually sane to do so. I know it's possible - it's what mac80211 in Linux does. * Make ieee80211_raw_xmit() queue a frame into VAP or parent queue rather than doing a short-cut direct into the driver. There are QoS issues here - you do want your management frames to be encapsulated and pushed onto the stack sooner than the (large, bursty) amount of data frames that are queued. But there has to be a saner way to do this. * Fragments are still broken - drivers need to be upgraded to an if_transmit() implementation and then fragmentation handling needs to be properly fixed. Tested: * STA - AR5416, AR9280, Intel 5300 abgn wifi * Hostap - AR5416, AR9160, AR9280 * Mesh - some testing by monthadar@, more to come.
|
#
3484d5ad |
|
15-Jan-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Remove the use of the ifnet send queue and if_start() in the power save queue code. Instead, use if_transmit() directly - and handle the cases where frame transmission fails. I don't necessarily like this and I think at this point the M_ENCAP check, node freeing upon fail and the actual if_transmit() call should be done in methods in ieee80211_freebsd.c, but I digress slightly.. This removes one of the last few uses of if_start() and the ifnet if_snd queue. The last major offender is ieee80211_output.c, where ieee80211_start() implements if_start() and uses the ifnet queue directly. (There's a couple of gotchas here, where the if_start pointer is compared to ieee80211_start(), but that's a later problem.)
|
#
e7f0d7cf |
|
02-Oct-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Migrate the power-save functions to be overridable VAP methods. This turns ieee80211_node_pwrsave(), ieee80211_sta_pwrsave() and ieee80211_recv_pspoll() into methods. The intent is to let drivers override these and tie into the power save management pathway. For ath(4), this is the beginning of forcing a node software queue to stop and start as needed, as well as supporting "leaking" single frames from the software queue to the hardware. Right now, ieee80211_recv_pspoll() will attempt to transmit a single frame to the hardware (whether it be a data frame on the power-save queue or a NULL data frame) but the driver may have hardware/software queued frames queued up. This initial work is an attempt at providing the hooks required to implement correct behaviour. Allowing ieee80211_node_pwrsave() to be overridden allows the ath(4) driver to pause and unpause the entire software queue for a given node. It doesn't make sense to transmit anything whilst the node is asleep. Please note that there are other corner cases to correctly handle - specifically, setting the MORE data bit correctly on frames to a station, as well as keeping the TIM updated. Those particular issues can be addressed later.
|
#
d745c852 |
|
06-Nov-2011 |
Ed Schouten <ed@FreeBSD.org> |
Mark MALLOC_DEFINEs static that have no corresponding MALLOC_DECLAREs. This means that their use is restricted to a single C file.
|
#
d91933f4 |
|
07-Jul-2011 |
Kevin Lo <kevlo@FreeBSD.org> |
Fix memset sizeofs Reviewed by: bschmidt
|
#
a7d5f7eb |
|
19-Oct-2010 |
Jamie Gritton <jamie@FreeBSD.org> |
A new jail(8) with a configuration file, to replace the work currently done by /etc/rc.d/jail.
|
#
e2126dec |
|
18-Dec-2008 |
Sam Leffler <sam@FreeBSD.org> |
convert MALLOC/FREE to malloc/free
|
#
63092fce |
|
25-Oct-2008 |
Sam Leffler <sam@FreeBSD.org> |
New ap-side power save implementation; the main change is to allow drivers to queue frames previously encapsulated on a separate high priority list that is dispatched before the unencapsulated frames (to preserve order).
|
#
c5abbba3 |
|
23-Oct-2008 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Revert the removal of the MALLOC and FREE macros from the net80211 code. Requested by: sam
|
#
1ede983c |
|
23-Oct-2008 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Retire the MALLOC and FREE macros. They are an abomination unto style(9). MFC after: 3 months
|
#
d7f03759 |
|
19-Oct-2008 |
Ulf Lilleengen <lulf@FreeBSD.org> |
- Import the HEAD csup code which is the basis for the cvsmode work.
|
#
b032f27c |
|
20-Apr-2008 |
Sam Leffler <sam@FreeBSD.org> |
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
|
#
b105a069 |
|
17-Sep-2007 |
Sam Leffler <sam@FreeBSD.org> |
Update beacon handling to sync w/ vap code base: o add driver callback to handle notification of beacon changes; this is required for devices that manage beacon frames themselves (devices must override the default handler which does nothing) o move beacon update-related flags from ieee80211com to the beacon offsets storage (or handle however a driver wants) o expand beacon offsets structure with members needed for 11h/dfs and appie's o change calling convention for ieee80211_beacon_alloc and ieee80211_beacon_update o add overlapping bss support for 11g; requires driver to pass beacon frames from overlapping bss up to net80211 which is not presently done by any driver o move HT beacon contents update to a routine in the HT code area Reviewed by: avatar, thompsa, sephe Approved by: re (blanket wireless)
|
#
68e8e04e |
|
10-Jun-2007 |
Sam Leffler <sam@FreeBSD.org> |
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
|