Imagine that bpf(9) tapping can happen at any point in the network stack,
not necessarily at interface transmit or receive. To achieve that we need
a thin layer of abstraction defined by struct bif_methods, that defines
how generic bpf layer works with a tap point of this kind.
Implement ifnet(9) specific methods in a separate file bpf_ifnet.c. At
this point there is 100% compatibility for all existing interfaces, there
is no KPI change, yet. The legacy attaching KPI is layered over new ifnet
agnostic KPI. The new KPI may change though, as we can implement multiple
DLTs per single tap point in a prettier fashion.
The new abstraction layer allows us to move all the 802.11 radio injection
hacks out of bpf.c into ieee80211_radiotap.c, so do that immediately as a
good proof of concept.
Reviewed by: bz
Differential Revision: https://reviews.freebsd.org/D53872
Add some accessors to the key data, key length and MIC data.
Document exactly what these mean.
There's at least a couple of drivers that access the key data field
directly and assume that the TX/RX MIC is available directly after the
data pointer, which bakes in the "key size is 128 bits" in subtle ways.
The goal here is to migrate the drivers and net80211 code to use
these methods rather than accessing wk_key directly and making assumptions
about wk_key and the copied key length (which the ioctl path definitely
does.)
Once that's done, it should be a lot easier to change the key API for
larger keys.
Differential Revision: https://reviews.freebsd.org/D52711
Reviewed by: thj
- Update related comments
- Remove from tools/tools/net80211
Reviewed by: imp, adrian
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D52726
net80211 has various places where null data / null qos data frames
are sent. However plenty of NICs shouldn't be sending them from
net80211 and it may even upset their 802.11n window / sequence number
tracking.
So add support here.
Differential Revision: https://reviews.freebsd.org/D52297
Reviewed by: bz
The commit in Fixes: introduced logging the output bits from
ieee80211_vht_get_vhtflags(). This ends up causing quite a lot
of logging when net80211 is doing things like processing
received beacons.
So just remove the logging; if it's needed again then a developer
can add it back to that location, or just use dtrace to capture
the return value.
Fixes: 4bf049bfee
Differential Revision: https://reviews.freebsd.org/D52142
Reviewed by: bz
Use '% IEEE80211_SEQ_RANGE' to limit the sequence numbers being
stored and retrieved to 0..4095 inclusive.
Differential Revision: https://reviews.freebsd.org/D52302
Reviewed by: bz
The initial thought of migrating the LinuxKPI 802.11 enum into net80211
for shared use did not work out well. Currently in the need for yet
another adjustment, I decided to undo/de-couple net80211 and
LinuxKPI 802.11 again.
The enum name now gets used in LinuxKPI based wifi drivers and it
turns out it is spelt differntly than what I used initially.
This creates a conflict.
net80211 still in the need to be able to express BW_320 in an uint8_t
will likely be fine with the current solution as well. Rename the
enum and prefixes in net80211 to "net80211" instead of "ieee80211".
Apart from the names/prefix we leave the values the same.
In LinuxKPI add the enum with the expected name and use it there
throughout to make modern versions of LinuxKPI based wifi drivers
compile.
Sponsored by: The FreeBSD Foundation
Fixes: ca389486a9, 2c8b0d6205
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D52064
Add support for sequence number offloading -
* Check IEEE80211_CONF_SEQNO_OFFLOAD() before doing TX lock
manipulation;
* Don't call ieee80211_output_seqno_assign() if
IEEE80211_CONF_SEQNO_OFFLOAD() is true.
TODO:
* this doesn't yet do beacon sequence number allocation offloading;
I'll tackle that later.
Differential Revision: https://reviews.freebsd.org/D50692
Reviewed by: bz
ieee80211_vht_get_vhtflags() is checking the htinfo IE for the
20/40MHz flag as part of deciding valid channel widths.
However, in the hostapd path, the ASSOC_REQ/REASSOC_REQ path
will parse the IEs, do some HT/VHT setup, then call
ieee80211_ht_updatehtcap_final(). In a HT ASSOC/REASSOC request
there won't be a HTINFO IE, however ieee80211_vht_get_vhtflags()
still checks for it, leading to a panic.
Instead, treat it as if we don't yet know if it's HT40 or not.
I'm not sure if we should do that or have it just do
_RETURN_CHAN_BITS(0).
Differential Revision: https://reviews.freebsd.org/D50794
Way back in 2017 I wrote the initial VHT hostap support, and then
added a NULL check here to stop it from panicing. However, there
is no VHTINFO IE in an ASSOC_REQ management frame. Thus, the node
would never have VHT state initialised.
This mirrors what HT node setup does (which again doesn't have
HTINFO IE's in an ASSOC_REQ frame), the upgrade will happen once
the exchange completes.
Fixes: 2023566223
Differential Revision: https://reviews.freebsd.org/D50787
Update ieee80211_output_seqno_assign() to support the transmitter
sequence number assignment outlined in 802.11-2020 10.3.2.14.2
(Transmitter Requirements).
Notably this correctly assigns the QoS NULL frames a seqno outside of
the TID seqno space.
Leave stub comments for the currently supported sequence
number decisions.
Add two new functions to access and increment the sequence number space,
which will ensure that things wrap correctly. This should simplify
drivers needing to constantly invent their own methods of fetching
and incrementing the sequence number space.
Differential Revision: https://reviews.freebsd.org/D50691
Reviewed by: bz
In ieee80211_sta_join() there are currently two ways to set
"do_ht": (1) after checking HT IEs are avail, and (2) after
checking VHT IEs are avail and we are not on 2GHz.
In the latter case no one checks that HT IEs are available and
when we hit ieee80211_ht_updateparams_final() htinfo may be NULL
and we panic.
Avoid this by only checking for VHT if do_ht was set.
No VHT without HT IEs.
While here switch do_ht to be a bool.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
PR: 287625
Fixes: 51172f62a7
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D50923
Switch to using sys/stdarg.h for va_list type and va_* builtins.
Make an attempt to insert the include in a sensible place. Where
style(9) was followed this is easy, where it was ignored, aim for the
first block of sys/*.h headers and don't get too fussy or try to fix
other style bugs.
Reviewed by: imp
Exp-run by: antoine (PR 286274)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1595
Migrate most LinuxKPI 802.11 definitions for HE IEs to net80211.
During that process also properly define them as most of them only
had dummy values. Some of the definitions are sparse; that is, only
the bits used by drivers so far were listed and annotated with the
standards section.
There seems to be little point to mangle the names and have two copies
of all these bit field definitions. We can add "_S" (shift/mask)
variants to those we need in net80211 (if we do).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D50677
Take the HE IE structures as they are used by drivers and put them
into net80211 rather than LinuxKPI. There is little need to
re-invent the wheel on those. They settled for long enough.
Do not export them by default to user space as some also overlap with
wpa and we still do not have a clear distinction for what is available
only in kernel and what to user space. In our case ifconfig(8)
is a consumer of these structs which it can setting WANT_NET80211 like
we have done for some VHT bits before.
Add struct net80211_he_cap which holds the IE fields but also a bool
and is meant to be put into ic/vap/ni. The bool will give us the same
naming for all layers rather than having individual flags in each part
which was highly confusing. In theory this struct should be in
ieee80211_var.h but that would pull things apart.
Extend struct ieee80211_mu_edca_param_set by a union as it will help
ifconfig(8) parsing the bk/be/vi/vo parts.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D50676
The original list of IEs got expanded from TLV to TLextTV.
If the T matches 255 then we have a second list of IEs where the
meaning of TL stays the same. That means the 1 octet extT is part
of the length and the value starts at ie+3.
Start populating the list with IEEE802.11-2020 and 802.11ax-2021
values.
They will be initially used to start decoding some of the announced IEs
for ifconfig [-v] list (scan|sta). That should help users with
AX-enabled APs to see this (rather than no or UNKNOWN_ELEMID_255 and
make debugging easier once we implement 11ax.
Sposored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D50674
Annotate a few which are obsolete (gone).
Naming as usual is questionable and I contemplated using the names
from wpa with a different prefix but then we end up with another mix.
While updating the reference to the newer standard I haven't made
a full pass again and I cannot say which version I used in 2020.
The motivation for this is to get rid of unknown IEs displayed in
ifconfig and elsewhere.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Fixes: 50982d26e4 (MMIC -> MGMT_MIC)
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D50671
The previous clean-ups to remove some direct ifp manipulation have
removed the need for if_private.h in these source files.
Differential Revision: https://reviews.freebsd.org/D50646
Reviewed by: bz
Convert the couple of uses of ifnet structure bits into ifnet
calls and remove the header.
Differential Revision: https://reviews.freebsd.org/D50645
Reviewed by: bz
Mechanically migrate printf() -> net80211_printf().
A few places looked like they should be using net80211_vap_printf(),
so migrate those appropriately.
Differential Revision: https://reviews.freebsd.org/D50644
Reviewed by: bz
Migrate the if_printf() calls to net80211_vap_printf(), which hides
the underlying ifp and the network stack.
Note: there are still a LOT of direct printf() calls in the codebase.
This is just a mostly mechanical conversion of if_printf() calls.
Differential Revision: https://reviews.freebsd.org/D50643
Reviewed by: bz
Not all OSes support if_printf(), printf(), etc, so start migrating
the printf / log routines into net80211 routines that are implemented
in ieee80211_freebsd.c .
Migrate ic_printf() to net80211_ic_printf() via a macro for testing.
Differential Revision: https://reviews.freebsd.org/D50642
Reviewed by: bz
Previous work made trimming the TKIP trailer an optional thing
based on what the driver indicated it did with the received
frame. However, for drivers that aren't populating an RX frame
with an rx status - notably iwn(4) - exposed this bug.
If the driver doesn't expose any RX status then just restore
the previous behaviour.
This matches what was done in the CCMP code in ccmp_decap().
Locally tested:
* iwn(4), STA mode, CCMP + TKIP groupwise network
Differential Revision: https://reviews.freebsd.org/D50638
Fixes: 731ff40069
MFC after: 3 days
Reviewed by: bz
Between 802.11ac-2013 and 802.11-2020 some fields were deprecated and the
way VHT160 and VHT80P80 are selected has changed.
In order to get onto VHT160 with modern APs adopt and support both the
deprecated as well as the new logic.
For simplicity of blocks we pull out the non-HT40 handling early on,
followed by the "use HT", followed by the deprectaed options and then
the 80Mhz channel width.
In all cases keep checking (a) what is locally supported, (b) what the
user has locally allowed (FVHT flags, [-]vht160 [-]vht80p80 [-]vht80
[-]vht40), as well as (c) what is announced. Provide possible fallbacks
to lower channel widths in all cases (but VHT20, which means VHT is
disabled).
With this enable VHT160 and VHT80P80 in the LinuxKPI 802.11 driver
compat code as well.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: thj
Differential Revision: https://reviews.freebsd.org/D49773
On drivers not supporting background scanning (not having announced
IEEE80211_C_BGSCAN) we repeatedly have seen scanning issues and
BGSCAN was "on" according to, e.g., ddb show com /a.
Turns out there are multiple problems:
(a) the ioctl scanreq code can pass IEEE80211_[IOC_]SCAN_BGSCAN in
(ifconfig wlanX scan will do so by default). That flag ends up
on flags in the scanning code which have no other checks, and
we are doing a BGSCAN.
So make sure BGSCAN is announced by the driver and enabled
(and it's STA mode for the full check) or filter the BGSCAN out.
(b) ieee80211_bg_scan() never checked if background scanning was
available/enabled. Do so now.
(c) ieee80211_swscan_start_scan_locked() as a consequence of (a) would
start the BGSCAN unconditionally. Also check for BGSCAN to be
available/enabled here.
Lastly, we should no longer reach ieee80211_swscan_bg_scan() without
background scanning being available/enabled, so document that fact
by placing a KASSERT. That will also help in case future changes
will open a new hole or there are further which I have not noticed.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D50513
* change ieee80211_get_vap_ifname() to use if_name()
* migrate the other references of ifp->if_xname to
ieee80211_get_vap_ifname()
Differential Revision: https://reviews.freebsd.org/D50407
Reviewed by: bz
* create ieee80211_vap_get_broadcast_address() to fetch the broadcast
MAC address for the given VAP
* refactor references to ifp->if_broadcastaddr ->
ieee80211_vap_get_broadcast_address()
Differential Revision: https://reviews.freebsd.org/D50406
Reviewed by: bz
Migrate both if_flags and if_drvflags out of most source files.
Ideally it'd only be referenced in ieee80211_freebsd.c, but for now
it also ignores references in ieee80211_ioctl.c.
* migrate if_flags set to if_setflags
* migrate if_flags get to if_getflags
* migrate if_drvflags get to if_getdrvflags
* add ieee80211_vap_ifp_check_is_monitor() and
ieee8021_vap_ifp_check_is_simplex() to abstract out the IFF_MONITOR
and IFF_SIMPLEX flag checks.
* add ieee80211_vap_ifp_check_is_running() and
ieee80211_vap_ifp_set_running_state() to represent what IFF_DRV_RUNNING
means (ie, mark the underlying OS network interface as active and
inactive.)
Notably this doesn't yet clear up OACTIVE; I need to better describe
that.
Differential Revision: https://reviews.freebsd.org/D50405
Reviewed by: bz
Refactor the two places where NET_EPOCH_ENTER; if_input; NET_EPOCH_EXIT
are called into a single spot in ieee80211_freebsd.c.
This removes both if_input references and puts all the NET_EPOCH stuff
into ieee80211_freebsd.c.
Differential Revision: https://reviews.freebsd.org/D50404
Reviewed by: bz
* Move references to IF_LLADDR() into ieee80211_freebsd.c
* Add a comment on one that I need to verify before I move it
* Implement ieee80211_vap_sync_mac_address() which syncs the VAP
mac address from the network interface MAC address.
This uses FreeBSD-isms (network epoch, IF_LLADDR()) so it shouldn't
be in net80211 itself.
Differential Revision: https://reviews.freebsd.org/D50023
Refactor out the sequence number assignment code for normal frames
and beacons.
Document the behaviour around fragments and packet lists.
Right now this should be a no-op; there's some verification code
in here to make sure that the TID selected by the existing code
matches the TID populated in the passed in mbuf/frame.
Locally tested:
* rtwn(4), STA mode
Differential Revision: https://reviews.freebsd.org/D49764
Reviewed by: bz
Document what ieee80211_free_mbuf() does. In particular, it handles
freeing a list of mbufs, as an 802.11 "frame" passed to drivers may be
a chain of 802.11 encapsulated fragmented frames.
Reviewed by: bz
* Document what the VAP and device transmit paths do.
Take care to note down the 802.11 fragment handling and node references.
* Almost none of the drivers (save ath(4), which I fixed a long time ago)
implement 802.11 fragments after the big VAP rework done years
and years ago. A few others announce support (mwl, ral, uath, wpi) but
I haven't validated them. I'll be doing that as part of this work.
* Add some comments in ieee80211_fragment() around how fragment node
references work.
Differential Revision: https://reviews.freebsd.org/D49765
We were seeing panics during ieee80211_sta_join() which seemed that
the ni->ni_chan was not valid anymore, which was true.
We also saw errors indicating data put into ni_ies became inalid.
The problem was that the ieee80211_scan_entry passed into
ieee80211_sta_join() (in the observed case from setmlme_assoc_sta())
became invalid during ieee80211_alloc_node().
As a result for the ni_chan case the the rateset and len in rates[1]
became invalid. Similarly for the IEs.
Make a (deep)copy of the scan entry in setmlme_assoc_sta() and return
the copy as once we leave ieee80211_scan_iterate() we can no longer
rely on the scan entry to be valid.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reported by: rm, ziaee, bz
Tested by: rm, ziaee, bz
PR: 286063
Reviewed by: adrian (,emaste)
Differential Revision: https://reviews.freebsd.org/D49865
The fast frames / A-MSDU aggregation code is calculating whether to
aggregate frames based on transmit time, which requires a frame length
calculation. Unfortunately this is another place where VHT rates
started showing up but weren't being handled.
This only shows up if IEEE80211_SUPPORT_SUPERG is enabled, which
isn't enabled by default (which means there's also no net80211
software driven A-MSDU assembly.)
So:
* Fetch the rate type
* Handle HT, LEGACY, VHT and UNDEFINED
* default UNDEFINED to 4ms, which should avoid the FF/A-MSDU aggregation
* default VHT to 1ms, to allow SOME possible A-MSDU aggregation where
possible.
There needs to be a bit more work done on HT/VHT for doing A-MSDU
with and without A-MPDU running, as that drastically changes the
math.
Differential Revision: https://reviews.freebsd.org/D49766
I didn't double check to see if ni_chw had been updated to actually
implement values other than 20/40. It's just implementing the
HT channel width stuff during both association and upon receiving
a HT TX channel width action frame.
This meant the VHT80/VHT160 transmit width checks were never
going to be true, as ni_chw is never set to VHT80 / VHT160.
After checking the HT action frame and looking for VHT changes,
I'm pretty sure there's nothing explicit about VHT width, as it's
normally done via CCA (clear channel access) and/or RTS/CTS exchanges -
each 20MHz subchannel is RTS/CTS'ed / will be checked and if they're
busy, a narrower frame will be transmitted.
So, change the VHT80 / VHT160 checks to only check if ni_chw is 20MHz.
If it's 20MHz then a HT action frame has come out saying to TX at 20MHz,
and we should obey it. Otherwise, do 80/160MHz as available.
Differential Revision: https://reviews.freebsd.org/D50096
Reviewed by: bz
An earlier commit relaxed the TA/RA rules around control frames
to fix other issues, however it now results in control frames
not specifically from a known node / to us to be handled in the control
path.
Specifically, rtwn(4) RTL8812/RTL8821 NICs are currently passing BARs
from the AP TA to any destination to us; which is tripping up BAW
tracking and causing traffic hangs.
So do the check before vap->iv_recv_ctl() is called in each input path.
Note that mesh doesn't seem to pass the control frames up; however
I haven't tested/validated mesh in a long while and I know it's
currently broken.
Differential Revision: https://reviews.freebsd.org/D49575
Drivers will set IEEE80211_FEXT_AMPDU_OFFLOAD to indicate to
net80211 that the driver or the firmware will handle AMPDU[-TX]
entirely on their own and net80211 should not do anything.
Following the IEEE80211_CONF_FRAG_OFFLOAD() example add a
IEEE80211_CONF_AMPDU_OFFLOAD() check in net80211 to handle the
condition.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D49829
For TKIP with iwlwifi we are seeing
DECRYPTED | ICV_STRIPPED | MMIC_STRIPPED.
In tkip_decap() we however unconditionally stripped the ICV which
resulted in a short frame and Gtk handshake never finished.
Add IEEE80211_RX_F_ICV_STRIP to net80211. Add the extra check to the
TKIP code.
While there correct a comment and leave another about contiguous data
assumptions.
In LinuxKPI 802.11 translate the new flag and sort them into STRIP
and FAIL while here.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D49880
The key alloc path was checking if the key was supported in hardware
but treated /all/ keys as supported in software. As I discovered
during my ath10k port, not all NICs that support ciphers in hardware
support enough of an 802.11 frame transmit/receive path to actually
handle software encryption.
So, do a second check after the hardware encryption check to see
if it's in the software list and hard fail it if it isn't in there.
Otherwise a fun failure mode occurs - the frames are marked as
protected, but since there's no GCMP support setup/enabled, they
just get marked as "protected" but they don't go through the
encryption path, and the receiver dutifully tosses them as invalid.
I've verified this by trying to use GCMP in wpa_supplicant with
a NIC that doesn't announce GCMP HW/SW encryption, and now it actually
fails.
Differential Revision: https://reviews.freebsd.org/D49393
Reviewed by: bz
The 802.11 specification specifically calls out that the GCMP AES
uses the CCMP AES specification, so we can re-use this here.
Changes during refactoring:
* the first block (b0) needs the priority field populated, which was
being done inline with the CCMP AAD assembly. So write a new function
that implements just that.
* Use IEEE80211_IS_QOS_ANY() in the AAD assembly; 802.11-2020
12.5.3.3.3 (Construct AAD) talks about frames with QoS control field,
not specifically QoS data frames (ie, not avoiding PS-POLL.)
* Use IEEE80211_IS_QOS_ANY() in the CCM nonce assembly.
Leave some verbose comments about the definition of "MPDU priority".
* mask the HTC/ORDER bit in the FC if the data frame contains a
QoS control field. Again, see 802.11-2020 12.5.3.3.3.
* Add extra comments about missing items and functionality for later
implementation.
Differential Revision: https://reviews.freebsd.org/D49367
Reviewed by: bz
Refactor CCMP-128 support and add CCMP-256 support.
This has been verified against openwrt on an ath9k device with
CCMP-256 + WPA-PSK-SHA256.
(And whilst I was at it, I also tested GCMP-256.)
Differential Revision: https://reviews.freebsd.org/D49238
Reviewed by: thj
