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
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
This allows a single wlan crypto module to register for more than
one cipher. Without it, duplicate linkerset structs are initialised
for the actual module loading machinery itself.
I've tested this in my private tree with wlan_ccmp providing both
128 and 256 bit cipher support.
Differential Revision: https://reviews.freebsd.org/D44901
Reviewed by: bz, cc, cy
Approved by: bz, cc, cy
This is effectively a no-op as we currently don't advertise these
ciphers as available anywhere.
Note though the intent to support 128 and 256 bit ciphers in the same
crypto module.
Differential Revision: https://reviews.freebsd.org/D44900
Reviewed by: cc, cy
Approved by: cc, cy
These are the bitmap / cipher module number fields used for net80211
ciphers.
This requires a kernel recompile, but nothing (currently) in userland
is using these.
Differential Revision: https://reviews.freebsd.org/D44899
Reviewed by: bz, cc
These are the rest of the ciphers and RSN flags from 802.11-2016.
* add the rest of the ciphers from 802.11-2016
* add the rest of the RSN flags from 802.11-2016
Of special interest here are the extended key ID field for supporting
>1 unicast key (to support seamless rekeying w/out dropping frames)
and the MFP (management frame protection) config bits.
This is a no-op; no code is using these new fields.
(In particular, no code in net80211 uses the RSN capability bits;
but that will change when we start on MFP support.)
Differential Revision: https://reviews.freebsd.org/D44864
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
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
First run the KASSERT before trying to do the free operation.
Better for reporting and debugging.
Add a guard setting the value to NULL afterwards. NULL pointers
are a lot easier to test for.
MFC after: 3 days
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43751
Turns out MFCing 713db49d06 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.
Since 5efea30f03 we can possibly lose a state transition which can
cause trouble further down the road.
The reproducer from 643d6dce6c 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
Both vap_update_preamble() and vap_update_ht_protmode() also check for
(*iv_erp_protmode_update)() rather than (*iv_preamble_update)()
or (*iv_ht_protmode_update)() before calling the later.
Use the appropriate NULL-function-pointer checks before calling it.
All seem unused currently so no functional changes expected.
MFC after: 3 days
Fixes: f1481c8d3b
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43655
It turned out thare various calls into (*iv_update_bss)(), that is
direct changes to vap->iv_bss in the old days, happened without
synchronisation.
Use locking assertions to document the requirement or status quo
at some callers given ic locking will eventually have to be dealt
with.
MFC after: 3 days
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43512
When ieee80211_sta_join1() gets an obss without ni_nt trying to lock
that will cause a NULL pointer deref. Check for the table to be
valid and deal with the obss node accordingly.
This can happen if sta_newstate() calls ieee80211_reset_bss() for
nstate == INIT and ostate != INIT. ieee80211_reset_bss() itself
calls ieee80211_node_table_reset() which calls node_reclaim()
which ends up in ieee80211_del_node_nt() which does remove the
node from the table and sets ni_table to NULL.
That node (former iv_bss) can then be returned as obss in the
(*iv_update_bss)() call in join1().
MFC after: 3 days
Reviewed by: adrian, cc
Differential Revision: https://reviews.freebsd.org/D43469
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
Replace ieee80211_ie_vhtcap with ieee80211_vht_cap and
ieee80211_ie_vht_operation with ieee80211_vht_operation.
The "ie" version has the two bytes type/length at the beginning which
we did not actually use as such (the one place doing did just as unused
extra work).
Using the non-"ie" versions allows us to re-use them on shared code.
Using an enum helps us to not accidentally get unsuppored or unhandled
values tough we cannot use it in the struct as we need to ensure the
field width.
ieee80211_vht_operation is guarded by _KERNEL/WANT_NET80211. While the
header is supposed to be exported to user land historically, software
such as wpa bring their own structure definitions. For in-tree usage
it is only ifconfig which really cares (at least for now).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian (earlier), cc
Differential Revision: https://reviews.freebsd.org/D42901
It is possible that we call ieee80211_new_state_locked() again before
a previous task finished to completion (not run yet or unlocked in
between) since 5efea30f03 (and follow-up).
In either case we would overwrite the new state and argument in the vap.
While most drivers somehow deal with that (or not), LinuxKPI 802.11 compat
code has KASSERTs to keep net80211, LinuxKPI and driver/firmware state in
sync and they may trigger due to a missing transition or more likely a
changed ni/lsta.
Enhance the wlandebug +state logging for these cases so they
are easier to debug.
While here remove the unconditional logging to the message buffer;
it has been here for a good decade but not helped to actually identify
and sort the problem.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D42560
In preparation for annotating copyin() and related functions with
__result_use_check.
Reviewed by: bz, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43095
Move the net_epoch into net80211 around the if_input calls and out of
the driver (in this first case LinuxKPI). This reduces coverage but
also allows us to alloc in calls like (*ampdu_rx_start) which do not
actually pass data up the stack.
The follow-up commits will revert b65f813c1a,
21c4082de9,
17c328b6ae,
af2441fbc7,
and 6c3e93cb5a for ath.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Tested by: few (rtwn, ath, iwlwifi, ...)
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D42427
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
Add an implementation of ieee80211_add_vhtcap() which works based on
information derived from the vap (and possibly channel/band but we do
not support that yet in net80211). This is needed for scans request
information in LinuxKPI at times before we have a BSS.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian, cc
Differential Revision: https://reviews.freebsd.org/D42422
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
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
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
Pass caller information to ieee80211_alloc_node() so that in case
IEEE80211_DEBUG_REFCNT is compiled in we can (better) track references,
in this case the initial ieee80211_node_initref().
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Make ieee80211_ref_node() a macro so we can pass __func__, __LINE__
in for IEEE80211_DEBUG_REFCNT as we do for other refcount related
functions. Add the appropriate IEEE80211_DPRINTF() call to the
_ieee80211_ref_node() implementation to support wlandebug(8) +node
printf style tracing.
As a plus we can now also use Dtrace fbt on the
_ieee80211_{ref,free}_node() implementations with futher logic,
gathering backtraces, etc. more flexibly.
Sponsored by: The FreeBSD Foundation
X-MFC: never
ieee80211_unref_node() was only used in two error cases in
ieee80211_send_nulldata(). There we do not need to guard against
ni pointer reuse after decrementing the refcount of the ni as we
only update the stats and return.
Update the man page and remove the link for the now gone function.
Sponsored by: The FreeBSD Foundation
X-MFC: never
Reviewed by: adrian, emaste
Differential Revision: https://reviews.freebsd.org/D42035
Looking through the allocation/free and reference cycle of nodes we have
a few (publicly) (almost) unused macros and functions.
Start making them private and reducing the amount of entry paths to the
same/similar functionality.
First is to make ieee80211_alloc_node() static as it is nowhere used
in the tree outside this file.
Sponsored by: The FreeBSD Foundation
X-MFC: no
Add more missing fields to the ddb output of sta (including spares so
people will notice if they use them to adjust ddb as well).
There are still more missing fields (some left as reminder in an
uncompiled __notyet__ block).
Add _db_show_rate() to print iv_rate as well optionally including
function pointers.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
We have multiple problems with scanning currently, one being that
an initial scan restarts itself and we are unable to start another
scan. wpa_supplicant in that case never shows scan results.
Starting wpa_cli you may see: <3>CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
messages.
Add two extra calls to ieee80211_notify_scan_done() at the end of scans
(before possible restarts). That will get wpa_supplicant to get
scan results and possibly start associating to a BSSID and get us out
of scan. This is kind-of a bandaid but on short notice may help to
improve the situation for some.
Based on analysis by: enweiwu
Submitted by: enweiwu (initial version)
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Tested by: cy, (others I cannot find email/PR for anymore)
Reviewed by: cy
Differential Revision: https://reviews.freebsd.org/D38661
While debugging other problems I ran into the case where net80211
was thinking a scan was ongoing and new scans could not be started
but given other logging there was clearly no more scan running.
It was hard after the fact to quickly determine enough state to
reconstruct or validate assumptions.
Improve a MSG_SCAN debug logging and implement _db_show_scan() ddb
output which can be printed along with show com /S or /a.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Mostly as documentation mark an unused argument to scan_curchan_task()
as __unused. We may possibly want to check all callers in the future
and see if the argument was supposed to be useful or should be entirely
removed.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
ath1xk drivers require further HE defines. Some of those we had
already predicted as comments in the past.
Sponsored by: The FreeBSD Foundation
MFC after: 10 days
iwlwifi already uses suggested EHT and U-SIG bits as well as some
more TLV bits. Update radiotap to know of those even if they might
get updated again in the future in order to get newer versions of
the driver to compile.
Sponsored by: The FreeBSD Foundation
MFC after: 10 days
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
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
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
