I added IEEE80211_TX_LOCK() a few years ago because there were races between
seqno allocation, driver queuing and crypto IV allocation. This meant that
they'd appear out of sequence and the receiver would drop them, leading to
terrible performance or flat out traffic hangs.
This flag should be set by drivers that do their own sequence number
allocation for all frames it needs to happen for, including beacon frames.
Eventually this should lead to the driver taking care of locking for
allocating seqno and other traffic-triggered events (eg addba setup.)
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. :/
This sets up:
* vht capabilities in vaps;
* calls vht_announce to announce VHT capabilities if any;
* sets up vht20, vht40 and vht80 channels, assuming the regulatory code
does the right thing with 80MHz available ranges;
* adds support to the ieee80211_add_channel_list_5ghz() code to populate
VHT channels, as this is the API my ath10k driver is using;
* add support for the freq1/freq2 field population and lookup that
VHT channels require.
The VHT80 code assumes that the regulatory domain already has limited VHT80
bands to, well, 80MHz wide chunks.
This is needed for two reasons:
* Drivers will need to know what the negotiated set of VHT capabilities
and rates are in order to configure (and reconfigure for opmode/chanwidth
changes) how to speak to a given peer; and
* Because some vendors are "special", we should be careful in what we announce
to them during peer association.
This isn't the complete solution, as I still need to make sure that when
sending out probe requests before we know what we want, we don't limit
the capabilities being announced. This is important for IBSS/mesh work
later on as probe request/response exchanges are the first hint at what
a peer supports. I'll look at adding that to the API soon.
This is a skeleton set based on ieee80211_ht.c. It implements some IE
parsing, some basic unfinished negotiation, and channel promotion/demotion.
However, by itself it's not enough to do VHT - notably, the actual
channel promotion for STA mode at least is done in ieee80211_ht.c as
part of htinfo_update_chw(). I was .. quite amused when I found that
out.
I'm checking this in so others can see progress rather than one huge
commit when VHT is "done" (which will likely be quite a while.)
* Add the VHT capability element to the driver capabilities so ifconfig
can see if VHT is available
* Add ioctl plumbing for enabling/disabling VHT and each of the VHT
widths.
Note: this DOES change the ABI (the driver caps ioctl struct size, sigh)
so this will require a recompile of at least ifconfig.
In preparation for VHT station support, we need to store VHT IEs when
scanning so we can choose to upgrade to VHT.
This doesn't change the ABI - it just steals spare[] entries.
The VHT operational element (VHTOPMODE) isn't a uint32_t - it's
the MCS sets, freq1/freq2 parameters and channel width.
So, store the channel width too in lieu of just storing the
IE struct.
This changes the VHT parameter layout in ieee80211_node but it
doesn't change ABI at all.
The 11n code uses these bits for both configuration /and/ controlling
the channel width on softmac chips - it uses it to find the widest
width for all VAPs (eg a HT20 vap and a HT40 vap) to know what to
configure the ic_curchan.
For fullmac devices it isn't /as/ important, as each virtual device
exposed by the firmware will likely have its own configuration and the
firmware figures out what to do to enable it.
These came from Linux mac80211 headers and are configuration bits, not
VHTOPMODE field parameters.
Whilst here, add the field names for the VHTCAP bits.
Tested:
* ath10k, 11ac STA mode
* rename the ieee80211com field for vht mcsinfo to be ic_, not iv;
* add a vht config field, stealing from the spares I left there.
This doesn't change the ABI.
The ath10k firmware supports hardware WEP offload, and in native wifi mode
(or 802.3 ethernet mode, for that matter) the WEP key isn't actually included
in the TX payload from net80211. Instead, a separate firmware command is issued
that sets the default TX key to be the specified key.
However, net80211 doesn't at all inform the driver layer that this is
occuring - it just "expects" to be inserting WEP header information
when doing WEP TX, even with hardware encryption.
So, to better support the newer world order, turn the default TX key assignment
into a VAP method that can be overridden by the driver and ensure its wrapped
in a crypto begin/end set. That way it should be correctly atomic from the
point of view of keychanges (as long as the driver does the right thing.)
It'd be nice if we passed through to the key_set call a flag that says
"also make this the default key" - that's captured here by calling the
deftxkey method after the key_set method. Maybe I can do that later.
Note: this is a net80211 ABI change, and will require a kernel+modules
recompile. Happy Holidays, etc.
Tested:
* ath10k driver port
* rtwn_usb, WEP station
This is a work in progress and some of this stuff may change;
but hopefully I'm laying down enough stuff and space in fields
to allow it to grow without another major recompile.
We'll see!
* Add a net80211 PHY type for VHT 2G and VHT 5G.
Note - yes, VHT is supposed to be for 5GHZ, however some vendors
(*cough* most of them) support some subset of VHT rate support
in 2GHz. No - not 80MHz wide channels, but at least some MCS8-9
support, maybe some beamforming, and maybe some longer A-MPDU
aggregates. I don't want to even think about MU-MIMO on 2GHz.
* Add an ifmedia placeholder type for VHT rates.
* Add channel flags for VHT, VHT20/40U/40D/80/80+80/160
* Add channel macros for the above
* Add ieee80211_channel fields for the VHT information and flags,
along with some padding (so this struct definitely grows.)
* Add a phy type flag for VHT - 'v'
* Bump the number of channels to a much higher amount - until we get
something like the linux mac80211 chanctx abstraction (where the
stack provides a current channel configuration via callbacks,
versus the driver ever checking ic->ic_curchan or similar) we'll
have to populate VHT+HT combinations.
Eg, there'll likely be a full set of duplicate VHT20/40 channels to match
HT channels. There will also be a full set of duplicate VHT80 channels -
note that for VHT80, its assumed you're doing VHT40 as a base, so we
don't need a duplicate of VHT80 + 20MHz only primary channels, only
a duplicate of all the VHT40 combinations.
I don't want to think about VHT80+80 or VHT160 for now - and I won't,
as the current device I'm doing 11ac bringup on (QCA9880) only does
VHT80.
I'll likely revisit the channel configuration and scanning related
stuff after I get VHT20/40 up.
* Add vht flags and the basic MCS rate setup to ieee80211com, ieee80211vap
and ieee80211_node in preparation for 11ac configuration.
There is zero code that uses this right now.
* Whilst here, add some more placeholders in case I need to extend
out things by some uint32_t flag sized fields. Hopefully I won't!
What I haven't yet done:
* any of the code that uses this
* any of the beamforming related fields
* any of the MU-MIMO fields required for STA/AP operation
* any of the IE fields in beacon frame / probe request/response handling
and the calculations required for shifting beacon contents around
when the TIM grows/shrinks
This will require a full rebuild of net80211 related programs -
ifconfig, hostapd, wpa_supplicant.
I'm teaching my ath10k port to communicate up the per-rate / channel width
information I get from the firmware.
The HT40 flag field should just be retired and instead moved to use the
PHY bandwidth field.
* ic_freq is the centre of the primary channel, not the centre of the
HT40/HT80/etc channel. Add a method to access that.
* Add a method to access the centre of the primary channel, including
knowing the centre of the 5/10/20/40/80, versus the primary channel.
Ie, it's the centre of the 40, 80, 160MHz channel.
* Add a method to access the centre frequency of the secondary 80MHz
channel - we don't support VHT yet, but when we do.
* Add methods to access the current channel and the per-dev desired
channel. Ideally drivers that do full offload with a per-vap channel
configuration should use the vap channel, NOT ic_curchan.
Non-offload drivers that require net80211 to change the channel should
be accessing ic_curchan.
TODO:
* drink real coffee before committing in the morning, or there's a high
risk of more obviously self-evident commits being turned into attempts
at humour.
Reported by: cem, Coverity CID 1366219
This just stores pointers to the IE; it doesn't yet parse anything.
Note: it blows out the size of ieee80211_node, so this will require
ye olde kernel/modules recompile.
* Pepper comments around which describe what state(s) we're in when faking
up 11n nodes.
* By default don't fake it up as 11n until we properly negotiate the 11n
capabilities using probe request/response frames.
* Send a probe request with our HT information, as the 802.11-2012 spec
suggests.
* Reassociate with the driver if we've been promoted.
This is done because although learning a peer via beacons can learn 11n
state, learning peers via hearing probe frames and broadcast frames
does not. Thus, sometimes you end up with an 11n peer in the peer
table and sometimes you don't.
Note that the probe request/response exchange may not actually succeed.
Ideally we'd put the peer into some blocking state until we've exchanged
probe request/reponse to learn capabilities, or we timeout and just
stay non-11n.
This is more an experiment to get 11n IBSS nodes actually discovering
each other and be able to transmit. There are other issues that creep
up which I'll attempt to address in future commits.
Tested:
* AR9380 NICs in 11n mode.
Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D8365
* teach the crypto modules about receive offload - although I have
to do some further reviewing in places where we /can't/ have an RX key
* teach the RX data path about receive offload encryption - check the flag,
handle NULL key, do decap and checking as appropriate.
Tested:
* iwn(4), STA mode
* ath(4), STA and AP mode
* ath10k port, STA mode (hardware encryption)
Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D8533
If full-offload scan is used, the NIC driver (or rather the firmware of
the NIC) should take care of interrupting and continuing the background
scan. So net80211 should ignore the vap->iv_bgscanidle setting then, instead
the NIC driver might look at this setting and pass it on to the firmware
in some way if possible.
Since full-offload scans won't be explicitly interrupted by net80211, it
also doesn't really make sense to check the vap->iv_bgscanidle condition
in that case, before starting a background scan. If the NIC driver
advertises background scan support and full-offload scanning, the firmware
should be able to execute that scan without interfering too much with our
data traffic.
Reviewed by: adrian, avos
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D8539
The 802.11-2012 specification notes that a subset of IEs should be present
in IBSS probe requests. This is what (initially) allows nodes to discover
that other nodes are 11n capable. Notably - HTCAP, but not HTINFO.
This isn't everything required to reliably enable 11n between net80211
peers; there's more work to come.
Tested:
* AR9380, IBSS+11n mode
