aboutsummaryrefslogtreecommitdiff
path: root/sys/net80211/ieee80211_ht.h
Commit message (Collapse)AuthorAgeFilesLines
* [net80211] Commit files missing in the previous commitAdrian Chadd2020-07-011-2/+3
| | | | | | | | These belong to my previous commit, but apparently I typed ieee80211_vhf.[ch] and forgot ht.h. Le oops. Notes: svn path=/head/; revision=362816
* [net80211] Handle offloaded AMSDU in AMPDU reordering.Adrian Chadd2020-06-131-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the 11n world, most NICs did A-MPDU receive/transmit offloading but not A-MSDU offloading. So, the net80211 A-MPDU receive path would just receive MPDUs, do the reordering bit, pass it up to the rest of net80211 for crypto decap and then do A-MSDU decap before throwing ethernet frames up to the rest of the system. However 11ac and 11ax NICs are increasingly doing A-MSDU offload (and newer 11ax stuff does socket offload, but hey I don't want to scare people JUST yet) - so although A-MPDU reordering may be done in the OS, A-MSDUs look like a normal MPDU. This means that all the MSDUs are actually faked into a set of MPDUs with matching 802.11 header - the sequence number, QoS header and any encryption verification bits (like IV) are just copied. This shows up as MASSIVE packet loss in net80211, cause after the first MPDU we just toss the rest. (And don't get me started about ethernet decap with A-MPDU host reordering; we'll have to cross that bridge for later 11ac and 11ax bits too.) Anyway, this work changes each A-MPDU reorder slot into an mbufq. The mbufq is treated as a whole set of frames to pass up to the stack and reordered/de-duped as a group. The last frame in the reorder list is checked to see if it's an A-MSDU final frame so any duplicates are correctly tossed rather than double-received. Other than that, the rest of the logic is unchanged. The previous commit did a small subset of this - if there wasn't any reordering going on then it'd accept the A-MSDUs. This is the rest of the needed work. This is a no-op for 11n NICs doing A-MPDU reordering but needing software A-MSDU decap - they aren't tagged as A-MSDU and so any subsequent frames added to the reorder slot are tossed. Tested: * QCA9880 (ath10k/athp) - STA/AP mode; * RT3593 (if_rsu) - 11n STA+DWDS mode (I'm committing through it rn); * QCA9380 (if_ath) - STA/AP mode. Notes: svn path=/head/; revision=362157
* [net80211] Fix this typo!Adrian Chadd2020-06-061-1/+1
| | | | | | | | I've just started using this macro in upcoming amsdu/ampdu/ff rework and yes, too many parens. Oops! Notes: svn path=/head/; revision=361864
* [net80211] Add initial A-MSDU in A-MPDU negotation support.Adrian Chadd2020-06-051-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is hopefully a big no-op unless you're running some extra patches to flip on A-MSDU options in a driver. 802.11n supports sending A-MSDU in A-MPDU. That lets you do things like pack small frames into an A-MSDU and stuff /those/ into an A-MPDU. It allows for much more efficient airtime because you're not wasting time sending small frames - which is still a problem when doing A-MPDU as there's still per-frame overhead and minimum A-MPDU density requirements. It, however, is optional for 802.11n. A lot of stuff doesn't advertise it (but does it, just wait!); and I know that ath10k does it and my ath(4) driver work supports it. Now, 802.11ac makes A-MSDU in A-MPDU something that can happen more frequently, because even though you can send very large A-MPDUs (like 1 megabyte and larger) you still have the small frame problem. So, 802.11ac NICs like ath10k and iwm will support A-MSDU in A-MPDU out of the box if it's enabled - and you can negotiate it. So, let's lay down the ground work to enable A-MSDU in A-MPDU. This will allow hardware like iwn(4) and ath(4) which supports software A-MSDU but hardware A-MPDU to be more efficient. Drivers that support A-MSDU in A-MPDU will set TX/RX htcap flags. Note this is separate from the software A-MSDU encap path; /that/ dictates whether net80211 is doing A-MSDU encapsulation or not. These HTC flags control negotiation, NOT encapsulation. Once this negotiation and driver bits are done, hardware like rtwn(4), run(4), and others will be able to use A-MSDU even without A-MPDU working; right now FF and A-MSDU aren't even attempted if you're an 11n node. It's a small hold-over from the initial A-MPDU work and I know how to fix it, but to flip it on properly I need to be able to negotiate or ignore A-MSDU in A-MPDU. Oh and the fun part - some 11ac APs I've tested will quite happily decap A-MSDU in A-MPDU even though they don't negotiate it when doing 802.11n. So hey, I know it works - I just want to properly handle things. :-) Tested: * AR9380, STA/AP mode Notes: svn path=/head/; revision=361825
* sys: general adoption of SPDX licensing ID tags.Pedro F. Giffuni2017-11-271-0/+2
| | | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=326272
* [net80211] prepare for A-MSDU/A-MPDU offload crypto / sequence number checking.Adrian Chadd2017-05-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When doing AMSDU offload, the driver (for now!) presents 802.11 frames with the same sequence number and crypto sequence number / IV values up to the stack. But, this will trip afoul over the sequence number detection. So drivers now have a way to signify that a frame is part of an offloaded AMSDU group, so we can just ensure that we pass those frames up to the stack. The logic will be a bit messy - the TL;DR will be that if it's part of the previously seen sequence number then it belongs in the same burst. But if we get a repeat of the same sequence number (eg we sent an ACK but the receiver didn't hear it) then we shouldn't be passing those frames up. So, we can't just say "all subframes go up", we need to track whether we've seen the end of a burst of frames for the given sequence number or not, so we know whether to actually pass them up or not. The first part of doing all of this is to ensure the ieee80211_rx_stats struct is available in the RX sequence number check path and the RX ampdu reorder path. So, start by passing the pointer into these functions to avoid doing another lookup. The actual support will come in a subsequent commit once I know the functionality actually works! Notes: svn path=/head/; revision=318566
* net80211: fix ieee80211_htrateset setup, return EINVAL for an unsupportedAndriy Voskoboinyk2017-03-031-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | ucast/mcast/mgmt HT rate. - Init global ieee80211_htrateset only once; neither ic_htcaps nor ic_txstream is changed when device is attached; - Move global ieee80211_htrateset structure to ieee80211com; there was a possible data race when more than 1 wireless device is used simultaneously; - Discard unsupported rates in ieee80211_ioctl_settxparams(); otherwise, an unsupported value may break connectivity (actually, 'ifconfig wlan0 ucastrate 8' for RTL8188EU results in immediate disconnect + infinite 'device timeout's after it). Tested with: - Intel 6205, STA mode. - RTL8821AU, STA mode. Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D9871 Notes: svn path=/head/; revision=314575
* [net80211] Initial VHT node upgrade/downgrade support and initial IE parsing.Adrian Chadd2017-01-131-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the bulk of the magic to start enabling VHT channel negotiation. It is absolutely, positively not yet even a complete VHT wave-1 implementation. * parse IEs in scan, assoc req/resp, probe req/resp; * break apart the channel upgrade from the HT IE parsing - do it after the VHT IEs are parsed; * (dirty! sigh) add channel width decision making in ieee80211_ht.c htinfo_update_chw(). This is the main bit where negotiated channel promotion through IEs occur. * Shoehorn in VHT node init ,teardown, rate control, etc calls like the HT versions; * Do VHT channel adjustment where appropriate Tested: * monitor mode, ath10k port * STA mode, ath10k port - VHT20, VHT40, VHT80 modes TODO: * IBSS; * hostap; * (ignore mesh, wds for now); * finish 11n state engine - channel width change, opmode notifications, SMPS, etc; * VHT basic rate negotiation and acceptance criteria when scanning, associating, etc; * VHT control/management frame handling (group managment and operating mode being the two big ones); * Verify TX/RX VHT rate negotiation is actually working correctly. Whilst here, add some comments about seqno allocation and locking. To achieve the full VHT rates I need to push seqno allocation into the drivers and finally remove the IEEE80211_TX_LOCK() I added years ago to fix issues. :/ Notes: svn path=/head/; revision=312015
* [net80211] implement "first RX defines the BAW" hack.Adrian Chadd2016-11-101-0/+1
| | | | | | | | | | | | | Unfortunately (sigh) some firmware doesn't provide the RX BA starting point, so we need to cope and set a "close enough" sequence number so we (hopefully!) don't discard frames as duplicates. Tested: * QCA9880v2, athp driver (under development), STA mode Notes: svn path=/head/; revision=308485
* [net80211] add a method to also explicitly tear down RX A-MPDU.Adrian Chadd2016-11-061-0/+1
| | | | | | | | | | | | The ath10k firmware API doesn't pass up the ADDBA/DELBA frames, only WMI firmware notifications. Tested: * ath10k (QCA9880), doing actual (ha!) 11n! Notes: svn path=/head/; revision=308383
* [net80211] add a HT method to populate HTCAP based on IBSS requirements.Adrian Chadd2016-09-171-0/+2
| | | | | | | | | | IBSS negotiation is a subset of the STA/AP negotiation. We always have a current channel, so base the HT capabilities on the current channel. This is then put into IBSS probe requests to inform peers of our 11n capabilities. Notes: svn path=/head/; revision=305895
* [net80211] Initial A-MSDU support for testing / evaluationAdrian Chadd2016-04-061-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A-MSDU is another 11n aggregation mechanism where multiple ethernet frames get LLC encapsulated (so they have a length field), padded, and put in a single MPDU (802.11 MAC frame.) This means it gets sent out as a single frame, with a single seqno, it's acked as one frame, etc. It turns out that, hah, atheros fast frames is almost but not quite like this, so I'm reusing all of the current superg/fast-frames stuff in order to actually transmit A-MSDU. Yes, this means that A-MSDU frames are also only aggregated two at a time, so it's not necessarily a huge win, but it's better than nothing. This doesn't do anything by default - the driver needs to say it does A-MSDU as well as set the AMSDU software TX capability so this code path gets exercised. For now, the only driver that enables this is urtwn. I'll enable it for rsu at some point soon. Tested: * Add an amsdu encap path to aggregate two frames, same as the fast-frames path. * Always do the superg init/teardown and node init/teardown stuff, regardless of whether the nodes are doing fast-frames (the ATH capability stuff.) That way we can reuse it for amsdu. * Don't do AMSDU for multicast/broadcast and EAPOL frames. * If we're doing A-MPDU, then don't bother doing FF/A-MSDU. We can likely do both together, but I don't want to change behaviour. * Teach the fast frames approx txtime logic to support the 11n rates. But, since we don't currently have a full "current rate" support, assume it's HT20, long-gi, etc. That way we overshoot on the TX time estimation, so we're always inside the requirements. (And we only aggregate two frames for now, so we're not really going to exceed that.) * Drop the maximum FF age default down to 2ms, otherwise we end up with some very annoyingly large latencies. TODO: * We only aggregate two ethernet frames, so I'm not checking the max A-MSDU size. But when it comes time to support >2 frames, we should obey that. Tested: * urtwn(4) Notes: svn path=/head/; revision=297603
* Abstract out the ampdu TX pps initialisation code so it can be reusedAdrian Chadd2015-09-281-0/+12
| | | | | | | | | | | | | | | | | | | | | in the superg fast-frames code. This harks back to an earlier commit (r280349) where I found that initialising the pps code with ticks=0 would cause hilariously bad hz ticks wraparound failures, leading to never actually aggregating traffic. This is still true for the superg path and so I have to do the same thing there. This is a big no-op; a subsequent commit will flip this on so it works with the fast-frames transmit path. Tested: * AR9170, otus(4) - STA mode, 11bg operation * AR9331, AP mode Notes: svn path=/head/; revision=288315
* Add external facing methods to control TX A-MPDU negotiaton.Adrian Chadd2015-09-221-0/+3
| | | | | | | | | | Some fullmac devices may rely on the stack starting it but not doing it. Whilst here, remove a duplicate LE_* macro definition, thanks to Andriy Voskoboinyk <s3erios@gmail.com>. Notes: svn path=/head/; revision=288085
* Add an external facing function to manually set the RX A-MPDU parametersAdrian Chadd2015-09-181-0/+3
| | | | | | | | | | | for re-ordering. Devices like if_rsu don't pass through action/management frames but do send firmware commands to inform us of things. One of those notifications is the RX A-MPDU negotiated parameters. Notes: svn path=/head/; revision=287948
* Migrate the net80211 TX aggregation state to be from per-AC to per-TID.Adrian Chadd2012-04-151-1/+1
| | | | | | | | | | | TODO: * Test mwl(4) more thoroughly! Reviewed by: bschmidt (for iwn) Notes: svn path=/head/; revision=234324
* Create a new task to handle 802.11n channel width changes.Adrian Chadd2012-03-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, a channel width change updates the 802.11n HT info data in net80211 but it doesn't trigger any device changes. So the device driver may decide that HT40 frames can be transmitted but the last device channel set only had HT20 set. Now, a task is scheduled so a hardware reset or change isn't done during any active ongoing RX. It also means that it's serialised with the other task operations (eg channel change.) This isn't the final incantation of this work, see below. For now, any unmodified drivers will simply receive a channel change log entry. A subsequent patch to ath(4) will introduce some basic channel change handling (by resetting the NIC.) Other NICs may need to update their rate control information. TODO: * There's still a small window at the present moment where the channel width has been updated but the task hasn't been fired. The final version of this should likely pass in a channel width field to the driver and let the driver atomically do whatever it needs to before changing the channel. PR: kern/166286 Notes: svn path=/head/; revision=233452
* Complete the MCS rate table based on the final 802.11n std. While hereBernhard Schmidt2011-03-101-1/+1
| | | | | | | | | adjust the IEEE80211_HTRATE_MAXSIZE constant, only MCS0 - 76 are valid the other bits in the mcsset IE (77 - 127) are either reserved or used for TX parameters. Notes: svn path=/head/; revision=219456
* Decrement rxa_pad due to the addition of rxa_private.Rui Paulo2010-04-291-1/+1
| | | | Notes: svn path=/head/; revision=207370
* Add a private field to struct ieee80211_rx_ampdu do hold driver specificRui Paulo2010-04-281-0/+1
| | | | | | | | | data. Sponsored by: iXsystems, inc Notes: svn path=/head/; revision=207327
* Revamp 802.11 action frame handling:Sam Leffler2009-07-051-4/+0
| | | | | | | | | | | | | | | | | o add a new facility for components to register send+recv handlers o ieee80211_send_action and ieee80211_recv_action now use the registered handlers to dispatch operations o rev ieee80211_send_action api to enable passing arbitrary data o rev ieee80211_recv_action api to pass the 802.11 frame header as it may be difficult to locate o update existing IEEE80211_ACTION_CAT_BA and IEEE80211_ACTION_CAT_HT handling o update mwl for api rev Reviewed by: rpaulo Approved by: re (kensmith) Notes: svn path=/head/; revision=195377
* pad data structures to enable integration of future features w/o abi breakageSam Leffler2009-06-011-0/+2
| | | | Notes: svn path=/head/; revision=193239
* promote ieee80211_seq typedefSam Leffler2009-05-021-2/+0
| | | | Notes: svn path=/head/; revision=191756
* o make %b msg bit defines public (to user apps too)Sam Leffler2009-01-271-0/+3
| | | | | | | o rename IEEE80211_C_CRYPTO_BITS to IEEE80211_CRYPTO_BITS Notes: svn path=/head/; revision=187797
* Sync BAR frame handling with out of tree work:Sam Leffler2008-10-251-4/+6
| | | | | | | | | | | | | | | | o correct BAR frame construction for AMPDU o retransmit BAR frames until ACK'd or timeout (use tunables to control behaviour, default is very aggressive) o defer seq# update until BAR frame is ACK'd o add BAR response handling callback for driver to interpose and push new state to device or push pending aggregates While here also: o add backpointer to node in the per-tid tx aggregation data structure o move ampdu tx state setup/teardown work to separate functions Notes: svn path=/head/; revision=184280
* Revamp ht ie handling:Sam Leffler2008-09-211-1/+4
| | | | | | | | | | | | | | | | | | o change ieee80211_parse_htcap and ieee80211_parse_htinfo to save only internal state obtained from the ie's; no dynamic state such as ni_chw is altered o add ieee80211_ht_updateparams to parse ht cap+info ie's and update dynamic node state o change ieee80211_ht_node_init to not take an htcap ie that is parsed; instead have the caller make a separate call as one caller wants to parse the ie while another wants to parse both cap+info ie's and update state so can better do this with ieee80211_ht_updateparams These changes fix sta mode state handling where the node's channel width was shifted to ht20/ht40 prematurely. Notes: svn path=/head/; revision=183254
* change ieee80211_ampdu_stop to take an explicit reason codeSam Leffler2008-09-211-1/+1
| | | | Notes: svn path=/head/; revision=183250
* Cleanup starting seq# for tx ampdu:Sam Leffler2008-09-211-2/+2
| | | | | | | | | o use txa_start to form the addba request and purge txa_seqstart o fill txa_start before calling ic_addba_request to permit drivers to override when they handle seq# generation (e.g. mwl) Notes: svn path=/head/; revision=183245
* moreve the aggregation q; it's not being used andSam Leffler2008-09-061-1/+0
| | | | | | | there's a better way to do this Notes: svn path=/head/; revision=182826
* move inline keyword to silence compiler complaintsSam Leffler2008-05-111-3/+3
| | | | Notes: svn path=/head/; revision=178951
* Multi-bss (aka vap) support for 802.11 devices.Sam Leffler2008-04-201-6/+78
| | | | | | | | | | | | | | 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) Notes: svn path=/head/; revision=178354
* add opaque pointer to tx ampdu state for driversSam Leffler2008-02-021-0/+1
| | | | | | | MFC after: 3 days Notes: svn path=/head/; revision=175880
* sync 11n support with vap code base; many changes based on interopSam Leffler2007-11-021-5/+15
| | | | | | | | | testing with all major vendors MFC after: 1 week Notes: svn path=/head/; revision=173273
* Update beacon handling to sync w/ vap code base:Sam Leffler2007-09-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | 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) Notes: svn path=/head/; revision=172211
* Update 802.11 wireless support:Sam Leffler2007-06-111-0/+113
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. Notes: svn path=/head/; revision=170530