This will be useful when fixing up the sequence number generation
and checks, as the rules around how sequence numbers are generated
have been clarified in 802.11-2016 and later. QoS-NULL frames are
explicitly marked as "any sequence number".
But for now, just create a macro and use it in the one place
it's currently being used as a check - ath(4).
* Add IEEE80211_IS_QOS_NULL().
* Change the "will this frame go into the TX block-ack window" check
in the ath(4) transmit path. Note this changes the check to be
more specific, but both paths already had previous checks to ensure
they're QoS data frames.
Locally tested:
* ath(4), AR9380, STA mode w/ AMPDU TX/RX enabled and negotiated
Differential Revision: https://reviews.freebsd.org/D47645
This is unused by anything in the tree; anything using it should be
instead using one of the frame type macros.
Differential Revision: https://reviews.freebsd.org/D47503
* Add macros for the management and control frame type checks that
I've come across in the drivers.
* Delete some now old code (eg ath's ieee80211_is_action()) as there's now
a macro for it.
Local testing:
* not yet, I have a lot of wifi devices to find and test against
Differential Revision: https://reviews.freebsd.org/D47500
* 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
* add the MMIC element ID
* add a comment showing the source of this table from the 802.11-2016
specification.
Differential Revision: https://reviews.freebsd.org/D46505
ieee80211_probe_curchan() passes a "force" argument which is bool.
Make it such. Adjust the (*sc_scan_probe_curchan)() KPI to bool
as well. This is all a big NOP as the only implementor of this
function, ieee80211_swscan_probe_curchan(), does not use the argument
at all.
I came across this when pondering a different scan implementation.
Rather than dropping the change remove the argument from the function,
and push the cleanup out given it is purely net80211 internal code
(the argument may have reason for existance in the future).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D45816
The RSN capability field may be the last two bytes in the IE.
802.11-2016 9.4.2.25.1 (General) doesn't require anything
afterwards - the PMKID/List and Group Management Cipher Suite
are optional.
Thus having a check of len > 2 will miss the situation where it
IS the last field.
This showed up when developing MFP, as I'm using optional MFP
at home and optional MFP doesn't encrypt group management frames.
(It should only add the BIP message integrity check IE in each
action frame.)
Differential Revision: https://reviews.freebsd.org/D45936
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
Change 4787572d05 made if_alloc_domain() never fail, then also do the
wrappers if_alloc(), if_alloc_dev(), and if_gethandle().
No functional change intended.
Reviewed by: kp, imp, glebius, stevek
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D45740
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
