net80211: clean up / add more macros to check the frame types

* Add new macros to check the version+type and version+type+subtype of a frame.
* Use these for existing frame checks.
* Convert the fla

net80211: clean up / add more macros to check the frame types

* Add new macros to check the version+type and version+type+subtype of a frame.
* Use these for existing frame checks.
* Convert the flag checks in net80211 to use the macros, rather than direct
header poking.

Notably I'm callign out things like QOS any versus QOS data, the
kind of NULL frames, etc. Eg, in the TKIP code it's checking whether
a frame is ANY kind of QOS frame, not just QOS data.

These macros should hopefully make the header checks clearer and less
error prone. They're also useful in drivers that are doing their
own header parsing.

Locally:

* ath(4), AP, STA, AP+STA modes
* local ath10k/athp - AP, STA modes
* rtwn - STA mode

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

show more ...

sys: Use mbufq_empty instead of comparing mbufq_len against 0

Reviewed by: bz, emaste
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D43338

net80211 amdpu: Simplify a few loops that drain an mbufq

These loops already handled a NULL return from mbufq_dequeue when the
queue was empty, so remove a redundant check of mbufq_len before
dequeu

net80211 amdpu: Simplify a few loops that drain an mbufq

These loops already handled a NULL return from mbufq_dequeue when the
queue was empty, so remove a redundant check of mbufq_len before
dequeueing.

Reviewed by: bz
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D43336

show more ...

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remov

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix

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$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\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: fix a typo in Rx MCS set for unequal modulation case

RX MCS set defines which MCSs are supported for RX, bits 0-31 are for equal
modulation of the streams, bits 33-76 are for unequal case.

net80211: fix a typo in Rx MCS set for unequal modulation case

RX MCS set defines which MCSs are supported for RX, bits 0-31 are for equal
modulation of the streams, bits 33-76 are for unequal case. Current code checks
txstreams variable instead of rxstreams to set bits from 53 to 76 for 4 spatial
streams case.

The modulations are defined in tables 19-38 and 19-41 of the IEEE Std
802.11-2020.

Spotted by bz in https://reviews.freebsd.org/D39476

Reviewed by: bz
Approved by: bz
Sponsored by: Serenity Cybersecurity, LLC
Differential Revision: https://reviews.freebsd.org/D39568

show more ...

net80211: wrong transmit MCS set in HT cap IE

Current code checks whether or not txstreams are equal to rxstreams and if it
isn't - sets needed bits in "Transmit MCS Set". But if they are equal it s

net80211: wrong transmit MCS set in HT cap IE

Current code checks whether or not txstreams are equal to rxstreams and if it
isn't - sets needed bits in "Transmit MCS Set". But if they are equal it sets
whole set to zero, which contradicts the standard, if tx and rx streams are
equal 'Tx MCS Set Defined' (table 9-186, IEEE Std 802.11-2020) must be set to
one.

Reviewed by: bz
Approved by: bz
Sponsored by: Serenity Cybersecurity, LLC
Differential Revision: https://reviews.freebsd.org/D39476

show more ...

net80211: consistently use the IEEE80211_M_ memory related options

Replace a malloc() by IEEE80211_MALLOC().
For malloc flags even in the local ieee80211_freebsd.c there was a mix
of both versions M

net80211: consistently use the IEEE80211_M_ memory related options

Replace a malloc() by IEEE80211_MALLOC().
For malloc flags even in the local ieee80211_freebsd.c there was a mix
of both versions M_ and IEEE80211_M_.
Consistently use the IEEE80211_M_ malloc options everywhere.
If the field is changed for malloc, it'll also be changed for the
other accessor functions taking a "how" field to avoid any confusion.

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

show more ...

net80211: fix -Wunused-but-set-variable warnings

Put the offending variables under the appropriate #ifdefs
(mostly IEEE80211_DEBUG, in one case IEEE80211_SUPPORT_SUPERG, and
in two cases under __not

net80211: fix -Wunused-but-set-variable warnings

Put the offending variables under the appropriate #ifdefs
(mostly IEEE80211_DEBUG, in one case IEEE80211_SUPPORT_SUPERG, and
in two cases under __notyet__ to revisit why these had been left
there but not used).

Sponsored by: The FreeBSD Foundation
MFC after: 10 days

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 ...

net: clean up empty lines in .c and .h files

MFH

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

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] 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] Handle offloaded AMSDU in AMPDU reordering.

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

[net80211] Handle offloaded AMSDU in AMPDU reordering.

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.

show more ...

[net80211] First part of A-MSDU offload handling - don't bump A-MPDU reordering seqno

When doing A-MSDU offload handling the driver is required to mark
A-MSDUs from the same MPDU with the same seque

[net80211] First part of A-MSDU offload handling - don't bump A-MPDU reordering seqno

When doing A-MSDU offload handling the driver is required to mark
A-MSDUs from the same MPDU with the same sequence number.
It then tags them as AMSDU (if it's a decap'ed A-MSDU) and AMSDU_MORE
(saying there's more AMSDUs decapped in the same MSDU.)
This allows encryption and sequence number offload to work right.

In the A-MSDU path the sequence number check looks at the A-MSDU flags
in the frame to see whether it's part of the same seqno and will pass them
(ie, not increment rx_seq until the last A-MSDU is seen from the driver,
or a new seqno shows up.0

However, I did this work in the A-MSDU path but not the A-MSDU in A-MPDU path.
For the non A-MDSU offload case the A-MPDU receive reordering will do its
thing and then pass up the MPDU up for decap - which then will see it's
an A-MSDU and decap each sub-frame. But this isn't done for offloaded
A-MSDU frames.

This requires two parts:

* Don't bump the RX sequence number, same as above; and
* If frames go into the reordering buffer, they need to be added into the slot
as a set of frames rather than a single frame, so once a new seqno shows up
this slot can be marked as "full" and we can move on.

This patch does the first. The latter requires that I find and commit
work to change rxa_m from an mbuf to an mbufq and the nhandle A-MSDU
there. But, the first is enough to allow the normal case (ie, no or not
a lot of A-MPDU RX reordering) to work.

This allows the athp driver (QCA9880) throughput to go from VERY low
(like 5mbit TCP, 1/3-1/4 expected UDP throughput) to ~ 250mbit TCP
and > 300mbit UDP on a VHT/40 channel. TCP sucks because, well, it
shows up as MASSIVE packet loss when all but one frame in a decap'ed
A-MSDU stream is dropped. Le whoops.

Now, where'd I put that laptop with the patch for rxa_m mbufq that
I wrote like in 2017...

Tested:

* AR9380, STA/AP mode (a big no-op, no A-MSDU hardware decap);
* if_run (RT3593), STA DWDS mode (A-MPDU / A-MSDU receive, but again
no A-MSDU hardware decap);
* QCA9880, STA/AP mode (which is doing hardware A-MPDU/A-MSDU decap,
but no A-MPDU reordering in the firmware.)

show more ...

[net80211] Add initial A-MSDU in A-MPDU negotation support.

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-

[net80211] Add initial A-MSDU in A-MPDU negotation support.

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

show more ...

[net80211] Add some TODOs around A-MSDU in A-MPDU negotiation.

net80211 currently doesn't negotiate A-MSDU in A-MPDU during ADDBA.
I've added the field in net80211 and this commit:

* Prints out the

[net80211] Add some TODOs around A-MSDU in A-MPDU negotiation.

net80211 currently doesn't negotiate A-MSDU in A-MPDU during ADDBA.
I've added the field in net80211 and this commit:

* Prints out the ADDBA field value during ADDBA;
* Adds some comments around where I need to follow up with some
negotiation logic.

Right now we don't have a driver flag anywhere which controls
whether A-MSDU in A-MPDU is allowed. I know it works (I have it
manually turned on at home on a couple test APs, heh!) but
I can't flip it on until we can negotiate it.

Tested:

* AR9380, STA/AP mode, printing out ADDBA requests

show more ...

Merge r358179 through r358238.

PR: 244251

Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (7 of many)

r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marke

Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (7 of many)

r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marked).
Use it in preparation for a general review of all nodes.

This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.

Mark all low hanging fruits as MPSAFE.

Reviewed by: markj
Approved by: kib (mentor, blanket)
Differential Revision: https://reviews.freebsd.org/D23626

show more ...

MFHead@r345275

net80211: correct check for SMPS node flags updates

Update node flags when driver supports SMPS, not when it is disabled or
in dynamic mode ((iv_htcaps & HTCAP_SMPS) != 0).

Checked with RTL8188EE (

net80211: correct check for SMPS node flags updates

Update node flags when driver supports SMPS, not when it is disabled or
in dynamic mode ((iv_htcaps & HTCAP_SMPS) != 0).

Checked with RTL8188EE (1T1R), STA mode - 'smps' word should disappear
from 'ifconfig wlan0' output.

MFC after: 2 weeks

show more ...