Commit Graph

1348 Commits

Author SHA1 Message Date
Bjoern A. Zeeb
af7d9f8e31 net80211: prefix get_random_bytes() with net80211_
Both linux/random.h and net80211 have a function named
get_random_bytes().  With overlapping files included these collide.
Arguably the function could be renamed in linuxkpi but the generic
name should also not be used in net80211 so rename it there.

Sponsored-by:	The FreeBSD Foundation
MFC-after:	2 weeks
Reviewed-by:	philip, adrian
Differential Revision:	https://reviews.freebsd.org/D29335
2021-03-24 22:16:09 +00:00
Bjoern A. Zeeb
c338cf2c6d net80211: split up ieee80211_probereq()
Factor out ieee80211_probereq_ie() and ieee80211_probereq_ie_len()
and make the length dynamic rather than static max.  The latter is
needed as our current fixed length was longer than some "hw scan",
e.g. that of ath10k, will take.  This way we can pass what we have.
Should this not be sufficient in the future we might have to deal
with filtering and much more error handling.

This also removes a duplicate calculation for ieee80211_ie_wpa [1].

Repoprted-by:	Martin Husemann <martin NetBSD.org> [1]
Sponsored-by:	Rubicon Communications, LLC ("Netgate")
Sponsored-by:	The FreeBSD Foundation (update for alloc)
Reviewed-by:	adrian, martin NetBSD.org (earlier version)
Reviewed-by:	philip
MFC-after:	2 weeks
Differential Revision: https://reviews.freebsd.org/D26545
2021-03-18 11:02:45 +00:00
Gordon Bergling
d197bf2b20 net80211: Fix a typo in a comment
- destionation -> destination
- while here, fix some whitespace issues

MFC after:	1 week
2021-03-13 15:51:30 +01:00
Bjoern A. Zeeb
3fca90af43 net80211: ratectl header guard against multiple inclusions
Add missing #ifndef/#define/#endif guards against multiple inclusions
to ieee80211_ratectl.h as they are missing.

MFC after:	3 days
Sponsored-by:	Rubicon Communications, LLC ("Netgate")
2021-03-07 17:35:58 +00:00
Bjoern A. Zeeb
a9cc796fa7 net80211: rx_stats add 160Mhz channel width.
Add the missing receive stat(u)s flag for 160Mhz channel width.
While here correct the comment for c_phytype to reference the correct
flags.

MFC-after:	3 days
Sponsored-by:	Rubicon Communications, LLC ("Netgate")
2021-02-28 19:24:22 +00:00
Bjoern A. Zeeb
60ec31e93f net80211: fix a typo
Correct a typo referring to the wrong flags in a comment.
No functional changes.

MFC after:	3 days
Sponsored by:	Rubicon Communications, LLC (d/b/a "Netgate")
2020-11-04 12:07:33 +00:00
Bjoern A. Zeeb
01e579408b net80211: factor out the priv(9) checks into OS specifc code.
Factor out the priv(9) checks into OS specifc code so other OSes can equally
implement them.  This sorts out those XXX in the net80211 code.
We provide 3 arguments (cmd, vap, ifp) where available to the functions, in
order to allow other OSes to use that data but also in case we'd add auditing
to these check to have the information available. For now the arguments are
marked __unused.

PR:		249403
Reported by:	martin(NetBSD)
Reviewed by:	adrian, martin(NetBSD)
MFC after:	10 days
Sponsored by:	Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision:	https://reviews.freebsd.org/D26541
2020-10-18 21:34:04 +00:00
Bjoern A. Zeeb
04e7bb08a5 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
2020-10-18 00:27:20 +00:00
Bjoern A. Zeeb
5152b4f74f net80211: whitespace
Fix indentation for the multi-line copies of
ieee80211_add_channel_list_5ghz() for the 3 bands.

MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
2020-10-07 22:52:24 +00:00
Bjoern A. Zeeb
1e375f3aa7 80211: non-functional changes
Sort a few VHT160 and 80+80 lines, update some comments, and remove
a superfluous ','.

No functional changes intended.

MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
2020-10-07 21:56:58 +00:00
Bjoern A. Zeeb
fe5ebb23cc 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
2020-09-24 10:57:39 +00:00
Mateusz Guzik
662c13053f net: clean up empty lines in .c and .h files 2020-09-01 21:19:14 +00:00
Bjoern A. Zeeb
2b9f12f6b2 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
2020-08-24 13:15:08 +00:00
Bjoern A. Zeeb
8f32e493cc net80211: improve media information for VHT5GHZ
Improve ieee80211_media_setup(), media2mode(), and
ieee80211_rate2media() for VHT5GHZ at least.

Reviewed by:	adrian, gnn
MFC after:	2 weeks
Sponsored by:	Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision:	https://reviews.freebsd.org/D26089
2020-08-23 21:42:23 +00:00
Bjoern A. Zeeb
30fdd33ca3 net80211: set_vht_extchan() reverse order to always return best
In set_vht_extchan() the checks are performed in the order of VHT20/40/80.
That means if a channel has a lower and higheer VHT flag set we would
return the lower first.
We normally do not set more than one VHT flag so this change is supposed
to be a NOP but follows the logical thinking order of returning the best
first. Also we nowhere assert a single VHT flag so make sure we'll not
be stuck with VHT20 when we could do more.

While here add the debugging printfs for VHT160 and VHT80P80 which still
need doing once we deal with a driver at that level.

Reviewed by:	adrian, gnn
MFC after:	2 weeks
Sponsored by:	Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision:	https://reviews.freebsd.org/D26088
2020-08-23 21:37:20 +00:00
Bjoern A. Zeeb
976485968e net80211: replace magic number by define
Rather than coding an array size of [4] replace the number with
WME_NUM_AC.

MFC after:	2 weeks
Reviewed by:	adrian
Sponsored by:	Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision:	https://reviews.freebsd.org/D26090
2020-08-17 20:18:01 +00:00
Bjoern A. Zeeb
97d9ee18a9 net80211: VHT correct NSS Set loop boundary
For the <VHT-MCS, NSS> tuple, NSS is 1..8 (or in our loop case 0..7
but not 0..6). Correct the boundry to check for < 8 and not < 7.

MFC after:	2 weeks
Reviewed by:	adrian
Sponsored by:	Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision:	https://reviews.freebsd.org/D26087
2020-08-17 20:16:33 +00:00
Bjoern A. Zeeb
a666b24ea5 net80211: return 80P80 before 160
In ieee80211_vht_get_chwidth_ie() we need to return 80P80 (3) before
VHT160 (2) as otherwise we'll never use 80P80.  Fix the order.

MFC after:	2 weeks
X-MFC with:	r364303 (which missed this)
Sponsored by:	Rubicon Communications, LLC (d/b/a "Netgate")
2020-08-17 16:51:21 +00:00
Bjoern A. Zeeb
372c7b9504 net80211: remove vertical whitespace
No functional changes.

MFC after:	2 weeks
Sponsored by:	Rubicon Communications, LLC (d/b/a "Netgate")
2020-08-17 16:28:59 +00:00
Bjoern A. Zeeb
4b1c248795 80211: consistently order 160 and 80+80
For flags and checks the order goes VHT160 and then VHT80P80 unless
checks are in reverse order ("more comes first") in which case we
deal with VHT80P80 first.
The one reverse order to pick out is where we check channel
prefernences.  While it may seem that VHT160 is better, finding
two "free" channels (VHT 80+80) is more likely so we do prefer that.

While dealing with VHT160 and VHT80P80 add extra clauses previously
missing or marked TODO in a few places.

Reviewed by:	adrian, gnn
MFC after:	2 weeks
Sponsored by:	Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision:	https://reviews.freebsd.org/D26002
2020-08-17 13:04:18 +00:00
Bjoern A. Zeeb
fd6eb8fec7 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
2020-08-17 12:52:57 +00:00
Bjoern A. Zeeb
96811be22f 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
2020-08-17 12:43:07 +00:00
Bjoern A. Zeeb
7d1d4407f5 net80211/ifconfig: print hardware device name for wlan interfaces
Add IEEE80211_IOC_IC_NAME to query the ic_name field and in ifconfig
to print the parent interface again. This functionality was lost
around r287197. It helps in case of multiple wlan interfaces and
multiple underlying hardware devices to keep track which wlan
interface belongs to which physical device.

Sponsored by:	Rubicon Communications, LLC (d/b/a "Netgate")
Reviewed by:	adrian, Idwer Vollering
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D25832
2020-08-07 12:24:23 +00:00
Adrian Chadd
f7d38a13a8 [net80211] Add new privileges; restrict what can be done in a jail.
Split the MANAGE privilege into MANAGE, SETMAC and CREATE_VAP.

+ VAP_MANAGE is everything but setting the MAC and creating a VAP.
+ VAP_SETMAC is setting the MAC address of the VAP.
  Typically you wouldn't want the jail to be able to modify this.
+ CREATE_VAP is to create a new VAP. Again, you don't want to be doing
  this in a jail, but this DOES stop being able to run some corner
  cases like Dynamic WDS (DWDS) AP in a jail/vnet. We can figure this
  bit out later.

This allows me to run wpa_supplicant in a jail after transferring
a STA VAP into it. I unfortunately can't currently set the wlan
debugging inside the jail; that would be super useful!

Reviewed by:	bz
Differential Revision:	https://reviews.freebsd.org/D25630
2020-07-19 15:16:27 +00:00
Adrian Chadd
39ca7ca568 [net80211] Commit files missing in the previous commit
These belong to my previous commit, but apparently I typed ieee80211_vhf.[ch]
and forgot ht.h.  Le oops.
2020-07-01 00:24:55 +00:00
Adrian Chadd
f1481c8d3b [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
2020-07-01 00:23:49 +00:00
Adrian Chadd
bac852bbac [net80211] Add missing commit to previous-1 uapsd commit.
Whoops; somehow my big commit line didn't include this..  cue the tree breakage emails.
2020-06-16 00:28:45 +00:00
Adrian Chadd
8379e8db7a [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.
2020-06-16 00:27:32 +00:00
Adrian Chadd
e9efad4f9e [net80211] Treat frames without an rx status as not a decap'ed A-MSDU.
Drivers for NICs which do A-MSDU decap in hardware / driver will need to
set the rx status, so if it's missing then treat it as not a decap'ed
A-MSDU.
2020-06-14 00:23:06 +00:00
Adrian Chadd
1209ded2e1 [net80211] Also convert the ddb path
Whoops - this belonged in my previous commit.
2020-06-14 00:21:48 +00:00
Adrian Chadd
e81d909274 [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.
2020-06-13 23:35:22 +00:00
Adrian Chadd
ea3d5fd9df [net80211] separate out node allocation and node initialisation.
This is a new, optional (for now!) method that drivers can use to separate
node allocation and node initialisation.  Right now they're the same, and
drivers that need to do node allocation via firmware commands need to sleep
and thus they need to defer node allocation into an internal taskqueue.

Right now they're just separate but not deferred.  Later on if I get the time
we'll start deferring the node and key related operations but that requires
making a bunch of other stuff (notably things that generate frames!) also
async/deferred.

Tested:

* RT3593, STA/DWDS mode
* AR9380, STA/AP modes
* QCA9880 (athp) - STA/AP modes
2020-06-13 22:20:02 +00:00
Conrad Meyer
8bc0d2b855 Fix !DEBUGNET build after r362138
X-MFC-With:	r362138
2020-06-13 03:16:09 +00:00
Conrad Meyer
479ab044c1 net80211: Add framework for debugnet(4) support
Allow net80211 drivers to register a small vtable of debugnet-related
methods.

This is not a functional change.  Driver support is needed, similar to
debugnet(4) for wired NICs.

Reviewed by:	adrian, markj (earlier version both)
Differential Revision:	https://reviews.freebsd.org/D17308
2020-06-13 00:59:36 +00:00
Adrian Chadd
a67acf111f [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.)
2020-06-12 04:19:03 +00:00
Adrian Chadd
ee424b7351 [net80211] ok ok if_xname won't ever be NULL.
Somewhere in net80211 if_xname is checked against NULL but it doesn't trigger
a compiler warning, but this does.  So DTRT for FreeBSD and the other if_xname
derefences can be converted to this function at a later time.
2020-06-10 18:59:46 +00:00
Adrian Chadd
24a366af3a [net80211] Add a method to return the vap's ifname.
This removes the requirement to know what's in the ifp.

(If someone wants a quick clean-up task, it'd be nice to convert instances
of ifp dereferencing for if_xname over to this method.)
2020-06-07 04:57:48 +00:00
Adrian Chadd
b3d0e274bf [net80211] Flip on A-MPDU, A-MSDU, A-MPDU+A-MSDU and Fast frames options.
This updates the logic to allow:

* A-MPDU if available;
* A-MSDU if available and A-MPDU is off/NACKed;
* A-MPDU+A-MSDU if it's available and negotiated;
* Fast frames if the node is 11abg (and not HT/VHT.)

This allows for things to fail back to A-MSDU or fast frames
if A-MPDU isn't available rather than needing to be non-HT/non-VHT.
It also allows A-MPDU+A-MSDU to work if it's negotiated.

Tested:

* AR9380, STA + AP mode (A-MPDU, A-MSDU, FF, A-MPDU+A-MSDU)
* RT5350, STA mode (A-MSDU, FF)
* AR9170, STA mode (A-MSDU, FF)
2020-06-06 22:25:00 +00:00
Adrian Chadd
4c3682159a [net80211] Fix this typo!
I've just started using this macro in upcoming amsdu/ampdu/ff rework and
yes, too many parens.  Oops!
2020-06-06 06:17:51 +00:00
Adrian Chadd
47bf877bde [net80211] Fix typo.
Oops!
2020-06-06 05:46:12 +00:00
Adrian Chadd
c3739eb66f [net80211] Don't call ic_updateslot if it's not set.
Turns out this isn't a required call. I didn't pick it up because my
uncommitted changes involve new updateslot methods for cards I'm working
on.

Dunce hat to: adrian
2020-06-05 14:17:19 +00:00
Adrian Chadd
48f25cc3c2 [net80211] print out node A-MSDU state.
Now that the node AMSDU TX/RX flags are correctly set in ieee80211_ht.c,
we can print out the AMSDU state here.
2020-06-05 07:38:46 +00:00
Adrian Chadd
ebb9b25672 [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
2020-06-05 07:38:10 +00:00
Adrian Chadd
d20ff6e680 [net80211] Migrate short slot time configuration into per-vap and deferred taskqueue updates.
The 11b/11g ERP and slot time update handling are two things which weren't
migrated into the per-VAP state when Sam did the initial VAP work.
That makes sense for a lot of setups where net80211 is driving radio state
and the radio only cares about the shared state.

However, as noted by a now deleted comment, the ERP and slot time updates
aren't EXACTLY correct/accurate - they only take into account the most
RECENTLY created VAP, and the state updates when one creates/destroys
VAPs isn't exactly great.

So:

* track the short slot logic per VAP;
* whenever the slot time configuration changes, just push it into a deferred
  task queue update so drivers don't have to serialise it themselves;
* if a driver registers a per-VAP slot time handler then it'll just get the
  per VAP one;
* .. if a driver registers a global one then the legacy behaviour is maintained -
  a single slot time is calculated and pushed out.

Note that the calculated slot time is better than the existing logic - if ANY
of the VAPs require long slot then it's disabled for all VAPs rather than
whatever the last configured VAP did.

Now, this isn't entirely complete - the rest of ERP tracking around short/long
slot capable station tracking needs to be converted into per-VAP, as well
as the preamble/barker flags.  Luckily those also can be done in a similar
fashion - keep per-VAP counters/flags and unify them before doing the driver
update.  I'll defer that work until later.

All the existing drivers can keep doing what they're doing with the global
slot time flags as that is maintained. One driver (iwi) used the per-VAP
flags instead of the ic flags, so now that driver will work properly.

This unblocks some ath10k porting work as the firmware takes the slot time
configuration per-VAP rather than globally, and some firmware handles
STA+AP and STA+STA (on same/different channels) configurations where
the firmware will switch slot time as appropriate.

Tested:

* AR9380, STA/AP mode
* AR9880 (ath10k), STA mode
2020-06-05 06:21:23 +00:00
Adrian Chadd
7280f37401 [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
2020-06-05 06:07:23 +00:00
Adrian Chadd
83fbae0ca6 [net80211] Add field definition for A-MSDU inside A-MPDU.
Now that I have A-MSDU and A-MPDU coexisting together, we need to actually
announce if (a) it's permitted and (b) figure out if we should use it
when transmitting.

This just adds the field; it doesn't yet include it in ADDBA exchanges.
2020-06-05 04:04:47 +00:00
Adrian Chadd
a6ca7ce3c2 [net80211] Add some more debugging during scanning
I'm trying to chase down more weird "I am not doing an incremental scan
when being asked" issues so these debugging statements help.
Notably, I've added more debugging around reasons why the scan is skipped -
eg because the cache is considered hot.

This should be a no-op unless you care about the debugging output!
2020-06-05 00:16:54 +00:00
Adrian Chadd
998bd62c31 [net80211] Print out a bad PN in both hex and decimal.
I've been using this to visually identify when I'm getting corrupted PNs
from the hardware. :(
2020-06-05 00:14:02 +00:00
Adrian Chadd
0b5aeb89eb [net80211] Send a probe request after IBSS node discovery
This sends a probe request after IBSS node discovery through
beacon frames. This allows things like HT and VHT capabilities
to be "negotiated" in adhoc mode.

It is .. kinda fire and pray - this isn't retried after discovery
so it's quite possible that nodes occasionally don't come up with
HT/VHT rate upgrades. At some point it may be a fun side project
to add support for retrying these probe requests/negotiations
after IBSS node discovery.

Tested:

* tested with multiple ath(4) NICs in 11n mode.

Differential Revision:	https://reviews.freebsd.org/D24979
2020-06-05 00:11:44 +00:00
Adrian Chadd
67a26c98f2 [net80211] Fix interrupted scan logic and ticks comparison
The scan task refactoring stuff circa 2014-2016 broke the blocking task
 into a taskqueue with some async bits, but it apparently broke scans
 being interrupted by traffic.

Notably - the new "field" SCAN_PAUSE sets both SCAN_INTERRUPT and SCAN_CANCEL,
and a bunch of existing code was checking for SCAN_CANCEL only and breaking
the scan. Unfortunately it was then (a) cancelling the scan entirely and
(b) not notifying userland that scan was done.

So:
* Update the calls to scan_end() to only pass in 1 (saying the scan is complete)
  if SCAN_CANCEL is set WITHOUT SCAN_INTERRUPT. If both are set then yes,
  the scan is interrupted, but it isn't canceled - it's just paused.
* Update the "did the scan flags change whilst the driver was called" logic
  to check for canceled scans, not interrupted scans.
* The "scan done" logic now explicitly checks for either interrupted or
  completed scans. This accounts for the situation where a scan is being
  aborted via traffic but it ALSO happens to have finished (ie the last
  channel was checked.)

This doesn't ENTIRELY fix scanning as the resume function is broken
due to incorrect ticks math. Thus, the second half of this patch
changes the ieee80211_ticks_*() macros to use int instead of long,
matching the logic that the TCP code does with ticks and handles
wrapping / negative ticks values. If cast to long then the wrapping
math wouldn't work right (ie, if ticks was actually negative,
ie, after the system has been up for a while.)

This allows contbgscan() to correctly calculate if a scan should
continue based on ticks and ic->ic_lastdata .

Reviewed by:	bz
Differential Revision:	https://reviews.freebsd.org/D25031
2020-05-27 18:32:12 +00:00