net80211: 11ac: add options to manage VHT STBC

Add IEEE80211_FVHT_STBC_(TX|RX) flags to allow userspace to manage
if STBC will be allowed for VHT RX/TX.
For RX this will only allow us to turn it off

net80211: 11ac: add options to manage VHT STBC

Add IEEE80211_FVHT_STBC_(TX|RX) flags to allow userspace to manage
if STBC will be allowed for VHT RX/TX.
For RX this will only allow us to turn it off but no fine grained
control of the number of supported spatial streams.

Introduce IEEE80211_FVHT_CHANWIDTH_MASK as a helper to make the
spelling out of the IEEE80211_FVHT_MASK more readable.

Update ifconfig to allow setting of these flags.

Sponsored by: The FreeBSD Foundation
MFC atfer: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D47838

show more ...

net80211: migrate the group/unicast key check into inline functions

The way that net80211 and drivers are checking for the /type/ of key
is to check if it's in the vap WEP key array and if so, it's

net80211: migrate the group/unicast key check into inline functions

The way that net80211 and drivers are checking for the /type/ of key
is to check if it's in the vap WEP key array and if so, it's a group
key. If not, it's a unicast key.

That's not only kind of terrible, but it's also going to be
problematic with future 802.11 support (for multiple unicast keys
and IGTK keys for management frame protection.)

So as part of this, remove the places where this is done and
instead use a pair inline functions - ieee80211_is_key_global() and
ieee80211_is_key_unicast(). They currenly still use the same logic
but the drivers and net80211 stack isn't doing it itself.

There are still open questions about why keys are not being
correctly tagged as GROUP, GTK, PTK, etc. That will be investigated
and addressed in follow-up work as a pre-cursor to MFP, IGTK, etc.
as mentioned above.

Testing:

* iwn, rtwn - STA mode

Differential Revision: https://reviews.freebsd.org/D45516

show more ...

net80211: fix IEEE80211_FHT_BITS

AMPDU_RX was added as a second AMPDU_TX, LDPC_TX and LDPC_RX missing;
correct and add missing.
Makes ddb output (and other debugging) look more correct.

Sponsored b

net80211: fix IEEE80211_FHT_BITS

AMPDU_RX was added as a second AMPDU_TX, LDPC_TX and LDPC_RX missing;
correct and add missing.
Makes ddb output (and other debugging) look more correct.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D45505

show more ...

net80211: add initial key management suites from 802.11-2016, APIs to register them

The WPA1/WPA2 driver capabilities aren't really enough in today's world.
There are a /lot/ more key management sui

net80211: add initial key management suites from 802.11-2016, APIs to register them

The WPA1/WPA2 driver capabilities aren't really enough in today's world.
There are a /lot/ more key management suites to support!

So, add initial support for net80211 and drivers to announce what
key management suites are supported. These are the list from 802.11-2016
section 9.4.2.25.3 (AKM suites.)

The flags are for software supported key management.

Drivers may support more key management suites and are welcome to
announce more; net80211 will only announce ones that we know
net80211 knows "enough" about to support correctly.

There /are/ other suites that may be interesting to some people in
the future that are not part of this set - eg if anyone ever
wants to support the Chinese WAPI standard - so this bitmap is not
specifically just the AKM suites in the RSN OUI.

This should eventually be communicated up to the wpa_supplicant and
hostapd via a replacement driver/vap capabilities call so they know
what to enable rather than just IEEE80211_C_WPA1 / IEEE80211_C_WPA2.

Differential Revision: https://reviews.freebsd.org/D44919
Reviewed by: bz

show more ...

net80211: add driver / crypto methods to set the hardware / software cipher suites

Drivers currently announce hardware crypto cipher support by
setting up ic_cryptocaps.

This adds two public functi

net80211: add driver / crypto methods to set the hardware / software cipher suites

Drivers currently announce hardware crypto cipher support by
setting up ic_cryptocaps.

This adds two public function calls:

* ieee80211_set_software_ciphers() - set the software cipher set;
* ieee80211_set_hardware_ciphers() - set the hardware cipher set.

For now these just call into the newly crypto routines to set the ciphers.

This then adds the two crypto routines, similarly named, to set
the hardware/software cipher suite.

This is a no-op right now - wep/tkip/ccmp are already set by default
so drivers aren't required to call these routines for software
encryption, and drivers already set ic_cryptocaps for hardware
encryption.

Differential Revision: https://reviews.freebsd.org/D44827

show more ...

net80211: add a new field specifically for announcing specific ciphers

This dates way, way back with the original net80211 support w/ atheros chips.

The earliest chip (AR5210) had limitations suppo

net80211: add a new field specifically for announcing specific ciphers

This dates way, way back with the original net80211 support w/ atheros chips.

The earliest chip (AR5210) had limitations supporting software encryption.
It only had the four WEP slots, and not any keycache entries. So when
trying to do CCMP/TKIP encryption would be enabled and the key slots
would have nothing useful in them, resulting in garbage encryption/decryption.

I changed this back in 2012 to disable supporting hardware WEP for AR5210
so if_ath(4) / net80211 crypto is all done in software and yes,
I could do CCMP/TKIP on AR5210 in software.

Fast-forward to newer-ish hardware - the Qualcomm 11ac hardware.
Those also don't support pass-through keycache slots! Well, the hardware
does at that layer, but then there's a whole offload data path encap/decap
layer that's turning the frames from raw wifi into ethernet frames (for
"dumb" AP behaviours) or "wifi direct" frames (ie, "windows".)
This hides a bunch of header frame contents required for doing the software
encryption / decryption path.

But then if you enable the raw transmit/receive frame format it ALSO
bypasses the hardware encryption/decryption engine!

So for those NICs:

* If you want to do encryption, you can only use the firmware supported
ciphers w/ wifi direct or ethernet;
* If you want to use software encrypt/decrypt, you MUST disable all encryption
and instead use 100% software encryption.

The wpa_supplicant bsd driver code has a specific comment about this and
flips on supporting WEP/TKIP/CCMP, which is understandable but it doesn't
fix the ACTUAL intention of all of this stuff.

So:

* create a new field, ic_sw_cryptocaps
* populate it with the default supported set of ciphers for net80211
(right now wep, tkip, ccmp)
* Communicate the combination of both ic_sw_cryptocaps and ic_cryptocaps
to wpa_supplicant via the relevant devcap ioctl.
* Update manpage.

I'll follow this up with a driver_bsd.c change in wpa_supplicant to
trust this again, and then start adding the other cipher support there.

Differential Revision: https://reviews.freebsd.org/D44820

show more ...

net80211: increase number of spares in struct ieee80211_vap

Turns out MFCing 713db49d06deee90dd358b2e4b9ca05368a5eaf6 does not
leave us with enough spares. Given wireless will likely see more
chang

net80211: increase number of spares in struct ieee80211_vap

Turns out MFCing 713db49d06deee90dd358b2e4b9ca05368a5eaf6 does not
leave us with enough spares. Given wireless will likely see more
changes in the near future add more spares.
This is especially necessary given 'struct ieee80211_vap' gets
allocated by drivers.
Bumps size of struct ieee80211_vap to (7 * 512) on 64bit.

show more ...

net80211: deal with lost state transitions

Since 5efea30f039c4 we can possibly lose a state transition which can
cause trouble further down the road.
The reproducer from 643d6dce6c1e can trigger the

net80211: deal with lost state transitions

Since 5efea30f039c4 we can possibly lose a state transition which can
cause trouble further down the road.
The reproducer from 643d6dce6c1e can trigger these for example.
Drivers for firmware based wireless cards have worked around some of
this (and other) problems in the past.

Add an array of tasks rather than a single one as we would simply
get npending > 1 and lose order with other tasks. Try to keep state
changes updated as queued in case we end up with more than one at a
time. While this is not ideal either (call it a hack) it will sort
the problem for now.
We will queue in ieee80211_new_state_locked() and do checks there
and dequeue in ieee80211_newstate_cb().
If we still overrun the (currently) 8 slots we will drop the state
change rather than overwrite the last one.
When dequeing we will update iv_nstate and keep it around for historic
reasons for the moment.

The longer term we should make the callers of
ieee80211_new_state[_locked]() actually use the returned errors
and act appropriately but that will touch a lot more places and
drivers (possibly incl. changed behaviour for ioctls).

rtwn(4) and rum(4) should probably be revisted and net80211 internals
removed (for rum(4) at least the current logic still seems prone to
races).

PR: 271979, 271988, 275255, 263613, 274003
Sponsored by: The FreeBSD Foundation (in 2023)
MFC after: 3 days
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43389

show more ...

net80211: migrate ic_vhtcaps, ic_vht_mcsinfo, ic_flags_vht

Like for the VAP rename ic_flags_vht to ic_vht_flags for consistency to
keep "VHT" fields together and merge ic_vhtcaps and ic_vht_mcsinfo

net80211: migrate ic_vhtcaps, ic_vht_mcsinfo, ic_flags_vht

Like for the VAP rename ic_flags_vht to ic_vht_flags for consistency to
keep "VHT" fields together and merge ic_vhtcaps and ic_vht_mcsinfo
into struct ieee80211_vht_cap ic_vht_cap.

While the structure layout changes no other functional changes intended.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian, cc
Differential Revision: https://reviews.freebsd.org/D42421

show more ...

net80211: combine iv_vhtcaps and iv_vht_mcsinfo

The iv_vhtcaps and iv_vht_mcsinfo fields together form
struct ieee80211_vht_cap so combine them into one field in the VAP
and keep the information tog

net80211: combine iv_vhtcaps and iv_vht_mcsinfo

The iv_vhtcaps and iv_vht_mcsinfo fields together form
struct ieee80211_vht_cap so combine them into one field in the VAP
and keep the information together.

While the structure layout changes no other functional changes intended.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian, cc
Differential Revision: https://reviews.freebsd.org/D42420

show more ...

net80211: rename iv_flags_vht to iv_vht_flags

While the flag field is internal start naming it as well as "iv_vht*"
so we keep all "VHT" fields together. This breaks with what was done
done for HT

net80211: rename iv_flags_vht to iv_vht_flags

While the flag field is internal start naming it as well as "iv_vht*"
so we keep all "VHT" fields together. This breaks with what was done
done for HT but with HE, EHT, .. coming one day seems the more logic
choice.

No functional changes intended.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian, cc
Differential Revision: https://reviews.freebsd.org/D42419

show more ...

sys: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

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

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

show more ...

net80211: change order in ieee80211_vhtchanflags()

While 80P80 is less likely to be used, VHT160 (a single contiguous
width) is harder to acquire but also preferable so return that first.

Sponsored

net80211: change order in ieee80211_vhtchanflags()

While 80P80 is less likely to be used, VHT160 (a single contiguous
width) is harder to acquire but also preferable so return that first.

Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D35977

show more ...

net80211: correct IEEE80211_FEXT_BITS

Correct IEEE80211_FEXT_BITS adding the missed one and move the later
one further. This will actually make VHT to show.

Sponsored by: The FreeBSD Foundation
MF

net80211: correct IEEE80211_FEXT_BITS

Correct IEEE80211_FEXT_BITS adding the missed one and move the later
one further. This will actually make VHT to show.

Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D35977

show more ...

net80211: introduce (*iv_update_bss)()

Introduce (*iv_update_bss)() with a default implementation to allow
drivers to overload/intercept the time when we swap iv_bss.

This helps firmware based driv

net80211: introduce (*iv_update_bss)()

Introduce (*iv_update_bss)() with a default implementation to allow
drivers to overload/intercept the time when we swap iv_bss.

This helps firmware based drivers to synchronize state with firmware.
Otherwise, for some state changes, we begin with one ni (and in
LinuxKPI lsta) and try to finish with another ni (and a new lsta
in different state) and may no longer have access to the previous state.
This also saves us from constantly checking for ni changes complicating
code.

No functional changes intended.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
X-MFC: move (*iv_update_bss) to spare area

show more ...

net80211: add func/line information to IEEE80211_DISCARD* macros

While debugging is very good in net80211, some log messages are
repeated in multiple places 1:1. In order to distinguish where the
d

net80211: add func/line information to IEEE80211_DISCARD* macros

While debugging is very good in net80211, some log messages are
repeated in multiple places 1:1. In order to distinguish where the
discard happened and to speed up analysis, add __func__:__LINE__
information to all these messages.

Sponsored by: The FreeBSD Foundation
MFC after: 1 week

show more ...

net80211: update for (more) VHT160 support

Implement two macros IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_IS_160MHZ()
and its 80+80 counter part to check in vhtcaps for appropriate
levels of support and use

net80211: update for (more) VHT160 support

Implement two macros IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_IS_160MHZ()
and its 80+80 counter part to check in vhtcaps for appropriate
levels of support and use the macros throughout the code.

Add vht160_chan_ranges/is_vht160_valid_freq and handle analogue
to vht80 in various parts of the code.

Add ieee80211_add_channel_cbw() which also takes the CBW flag
fields and make the former ieee80211_add_channel() a wrapper to it.
With the CBW flags we can add HT/VHT channels passing them to
getflags() for the 2/5ghz functions.

In ifconfig(8) add the regdomain_addchans() support for VHT160
and VHT80P80.

With this (+ regdoain.xml updates) VHT160 channels can be
configured, listed, and pass regdomain where appropriate.

Tested with: iwlwifi
Reviewed by: adrian
MFC after: 10 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26712

show more ...

Provide MS() and SM() macros for 80211 and wireless drivers.

We have (two versions) of MS() and SM() macros which we use throughout
the wireless code. Change all but three places (ath_hal, rtwn, an

Provide MS() and SM() macros for 80211 and wireless drivers.

We have (two versions) of MS() and SM() macros which we use throughout
the wireless code. Change all but three places (ath_hal, rtwn, and rsu)
to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK()
macros. Also change one internal case using both _S and _M instead of
just _S away from _M (one of the reasons rtwn and rsu were not changed).

This was done semi-mechanically. No functional changes intended.

Requested by: gnn (D26091)
Reviewed by: adrian (pre line wrap)
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision: https://reviews.freebsd.org/D26539

show more ...

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)

net80211: enhance getflags*() and ieee80211_add_channel*()

For ieee80211_add_channel+*() we are passing in an int flag for
ht40 and in some cases another int flag for vht80 where we'd only
need two

net80211: enhance getflags*() and ieee80211_add_channel*()

For ieee80211_add_channel+*() we are passing in an int flag for
ht40 and in some cases another int flag for vht80 where we'd only
need two bits really.
Convert these variables to a bitflag and fold them together into one.
This also allows for VHT160 and VHT80P80 and whatever may come to
be considered. Define the various options currently needed.

Change the drivers (rtwn and rsu) which actually set this bit to non-0.
For convenience the "1" currently used for HT40 is preserved.

Enahnce getflags_5ghz() to handle the full set of VHT flags based
on the input flags from the the driver.

Update the regdomain implementation as well to make use of the new
flags and deal with higher [V]HT bandwidths.

ieee80211_add_channel() specifically did not take flags so it will
not support naything beyond 20Mhz channels.

Note: I am not entirely happy with the "cbw_flag[s]" name, but we
do use chan_flags elsewhere already.

MFC after: 2 weeks
Reviewed by: adrian, gnn
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential revision: https://reviews.freebsd.org/D26091

show more ...

80211: consistently spell 80P80

The standard uses 80+80 and 80p80 but nowhere 80_80.
Switch the latter to 80P80 for all the macros and comments refering
to #defined flags which I could find.
The onl

80211: consistently spell 80P80

The standard uses 80+80 and 80p80 but nowhere 80_80.
Switch the latter to 80P80 for all the macros and comments refering
to #defined flags which I could find.
The only place we leave as 80p80 is the ifconfig command line arguments
as we spell them all in lower case.
Ideally we would use 80+80 for any interactions with the user and
80P80 for anything internal but let us not confuse parsers and
hence avoid the '+' in either case.

Reviewed by: adrian, gnn
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision: https://reviews.freebsd.org/D26001

show more ...

net80211 / ifconfig: cleanup the use of IEEE80211_FVHT_USEVHT*

Rather then using magic numbers duplicate IEEE80211_FVHT_VHT* in
ifconfig (cleanup of these and other flags used and not exposed by
net

net80211 / ifconfig: cleanup the use of IEEE80211_FVHT_USEVHT*

Rather then using magic numbers duplicate IEEE80211_FVHT_VHT* in
ifconfig (cleanup of these and other flags used and not exposed by
net80211 should happen later) and use those.
In the kernel this simplifies one ioctl path (the other one currently
relies on individual bit flags being passed in).
We also re-order the 80P80 and 160 flag for 160 to come before 80+80
and more clearly leave the flags as TODO in one of the 160/80+80 cases.

Reviewed by: adrian
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision: https://reviews.freebsd.org/D26000

show more ...

[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, leavin

[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

show more ...

[net80211] Add initial U-APSD negotiation support.

U-APSD (unscheduled automatic power save delivery) is a power save method
that's a bit better than legacy PS-POLL - stations can mark frames with
a

[net80211] Add initial U-APSD negotiation support.

U-APSD (unscheduled automatic power save delivery) is a power save method
that's a bit better than legacy PS-POLL - stations can mark frames with
an extra flag that tells the AP to leak out more frames after it sends
its own frames rather than needing to send a PS-POLL to get another frame
from the AP.

Now, this code just handles the negotiation bits; it doesn't actually
implement U-APSD. That's up to drivers, and nothing in the tree yet
implements this. I /may/ implement this for ath(4) if I eventually care
enough but right now I plan on just implementing it for firmware offload
based NICs that handle this in the NIC.

I'll commit the ifconfig bit after this and I may have some follow-up
commits as this gets used more by me in local testing.

This should be a glorious no-op for everyone else. If things change
for anyone that isn't fixed by a complete recompile then please reach out
to me.

show more ...