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
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
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
Summary:
In preparation of making if_t completely opaque outside of the netstack,
explicitly include the header. <net/if_var.h> will stop including the
header in the future.
Sponsored by: Juniper Networks, Inc.
Reviewed by: glebius, melifaro
Differential Revision: https://reviews.freebsd.org/D38200
Going through the Frame (Sub)types the "QOS Data" being called "QOS"
scheme leads to a naming conflict for QOS_CFPOLL and QOS_CFACKPOLL
(if added). Rename QOS* to QOS_DATA* to avoid the conflict and
to also better match the standards name.
No functional changes intended.
Sponsored by: The FreeBSD Foundation
MFC after: 5 days
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D36409
Replace a malloc() by IEEE80211_MALLOC().
For malloc flags even in the local ieee80211_freebsd.c there was a mix
of both versions M_ and IEEE80211_M_.
Consistently use the IEEE80211_M_ malloc options everywhere.
If the field is changed for malloc, it'll also be changed for the
other accessor functions taking a "how" field to avoid any confusion.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D36249
Summary: This returns whether the given 802.11 frame has the protected bit set.
Test Plan:
* tested in AP/STA mode
* STA mode - local athp/ath10k driver
* AP mode - in tree ath driver
Subscribers: imp, melifaro, glebius
Reviewed by: bz
Approved by: bz
Differential Revision: https://reviews.freebsd.org/D36183
Put the offending variables under the appropriate #ifdefs
(mostly IEEE80211_DEBUG, in one case IEEE80211_SUPPORT_SUPERG, and
in two cases under __notyet__ to revisit why these had been left
there but not used).
Sponsored by: The FreeBSD Foundation
MFC after: 10 days
No longer accept plaintext A-MSDU frames that start with an RFC1042
header with EtherType EAPOL. This is done by only accepting EAPOL
packets that are included in non-aggregated 802.11 frames.
Note that before this patch, FreeBSD also only accepted EAPOL frames
that are sent in a non-aggregated 802.11 frame due to bugs in
processing EAPOL packets inside A-MSDUs. In other words,
compatibility with legitimate devices remains the same.
This relates to section 6.5 in the 2021 Usenix "FragAttacks" (Fragment
and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation)
paper.
Submitted by: Mathy Vanhoef (Mathy.Vanhoef kuleuven.be)
Security: CVE-2020-26144
PR: 256120
MFC after: 7 days
Differential Revision: https://reviews.freebsd.org/D30665
Mitigate A-MSDU injection attacks by detecting if the destination address
of a subframe equals an RFC1042 (i.e., LLC/SNAP) header, and if so
dropping the complete A-MSDU frame. This mitigates known attacks,
although new (unknown) aggregation-based attacks may remain possible.
This defense works because in A-MSDU aggregation injection attacks, a
normal encrypted Wi-Fi frame is turned into an A-MSDU frame. This means
the first 6 bytes of the first A-MSDU subframe correspond to an RFC1042
header. In other words, the destination MAC address of the first A-MSDU
subframe contains the start of an RFC1042 header during an aggregation
attack. We can detect this and thereby prevent this specific attack.
This relates to section 7.2 in the 2021 Usenix "FragAttacks" (Fragment
and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation)
paper.
Submitted by: Mathy Vanhoef (Mathy.Vanhoef kuleuven.be)
Security: CVE-2020-24588
PR: 256119
Differential Revision: https://reviews.freebsd.org/D30664
ieee80211_defrag() accepts fragmented 802.11 frames in a protected Wi-Fi
network even when some of the fragments are not encrypted.
Track whether the fragments are encrypted or not and only accept
successive ones if they match the state of the first fragment.
This relates to section 6.3 in the 2021 Usenix "FragAttacks" (Fragment
and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation)
paper.
Submitted by: Mathy Vanhoef (Mathy.Vanhoef kuleuven.be)
Security: CVE-2020-26147
PR: 256118
Differential Revision: https://reviews.freebsd.org/D30663
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
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
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.
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
No functional change intended.
When doing AMSDU offload, the driver (for now!) presents 802.11 frames with
the same sequence number and crypto sequence number / IV values up to the stack.
But, this will trip afoul over the sequence number detection.
So drivers now have a way to signify that a frame is part of an offloaded
AMSDU group, so we can just ensure that we pass those frames up to the
stack.
The logic will be a bit messy - the TL;DR will be that if it's part of
the previously seen sequence number then it belongs in the same burst.
But if we get a repeat of the same sequence number (eg we sent an ACK
but the receiver didn't hear it) then we shouldn't be passing those frames
up. So, we can't just say "all subframes go up", we need to track
whether we've seen the end of a burst of frames for the given sequence
number or not, so we know whether to actually pass them up or not.
The first part of doing all of this is to ensure the ieee80211_rx_stats
struct is available in the RX sequence number check path and the
RX ampdu reorder path. So, start by passing the pointer into these
functions to avoid doing another lookup.
The actual support will come in a subsequent commit once I know the
functionality actually works!
This is the bulk of the magic to start enabling VHT channel negotiation.
It is absolutely, positively not yet even a complete VHT wave-1 implementation.
* parse IEs in scan, assoc req/resp, probe req/resp;
* break apart the channel upgrade from the HT IE parsing - do it after the
VHT IEs are parsed;
* (dirty! sigh) add channel width decision making in ieee80211_ht.c htinfo_update_chw().
This is the main bit where negotiated channel promotion through IEs occur.
* Shoehorn in VHT node init ,teardown, rate control, etc calls like the HT
versions;
* Do VHT channel adjustment where appropriate
Tested:
* monitor mode, ath10k port
* STA mode, ath10k port - VHT20, VHT40, VHT80 modes
TODO:
* IBSS;
* hostap;
* (ignore mesh, wds for now);
* finish 11n state engine - channel width change, opmode notifications, SMPS, etc;
* VHT basic rate negotiation and acceptance criteria when scanning, associating, etc;
* VHT control/management frame handling (group managment and operating mode being
the two big ones);
* Verify TX/RX VHT rate negotiation is actually working correctly.
Whilst here, add some comments about seqno allocation and locking. To achieve
the full VHT rates I need to push seqno allocation into the drivers and
finally remove the IEEE80211_TX_LOCK() I added years ago to fix issues. :/
* teach the crypto modules about receive offload - although I have
to do some further reviewing in places where we /can't/ have an RX key
* teach the RX data path about receive offload encryption - check the flag,
handle NULL key, do decap and checking as appropriate.
Tested:
* iwn(4), STA mode
* ath(4), STA and AP mode
* ath10k port, STA mode (hardware encryption)
Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D8533
- Add few checks for group/pairwise ciphers into
ieee80211_parse_{wpa,rsn}().
- Split error code and cipher value in wpa_cipher() / rsn_cipher(); current
hack with (1 << 32) does not work - it's 1, not 0 (detected by CSA).
- Return IEEE80211_REASON_UNSUPP_RSN_IE_VERSION instead of
IEEE80211_REASON_IE_INVALID when version field is not equal to RSN_VERSION.
Tested with wpi(4) / urtwn(4) (HOSTAP mode).
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D7887
Remove 'if_inc_counter(ifp, IFCOUNTER_OPACKETS, 1);' from raw xmit
and apbridge path; it will be incremented by ieee80211_tx_complete()
after packet transmission.
Noticed by: Imre Vadasz <imre@vdsz.com>
ieee80211.c:
add_chanlist(): 'error' variable will be uninitialized if
no channels were passed; return '0' instead.
ieee80211_action.c:
ieee80211_send_action_register(): drop 'break' after 'return'.
ieee80211_crypto_none.c:
none_encap(): 'keyid' is not used in non-debug builds; hide it
behind IEEE80211_DEBUG ifdef.
ieee80211_freebsd.c:
Staticize global 'ieee80211_debug' variable (used only in this
file).
ieee80211_hostap.c:
Fix a comment (associatio -> association).
ieee80211_ht.c:
ieee80211_setup_htrates(): initialize 'maxunequalmcs' to 0 to mute
compiler warning.
ieee80211_hwmp.c:
hwmp_recv_preq(): copy 'prep' between conditional blocks to fix
-Wshadow warning.
ieee80211_mesh.c:
mesh_newstate(): remove duplicate 'ni' definition.
mesh_recv_group_data(): fix -Wempty-body warning in non-debug
builds.
ieee80211_phy.c:
ieee80211_compute_duration(): remove 'break' after panic() call.
ieee80211_scan_sta.c:
Hide some TDMA-specific macros under IEEE80211_SUPPORT_TDMA ifdef
adhoc_pick_bss(): remove 'ic' pointer redefinition.
ieee80211_sta.c:
sta_beacon_miss(): remove 'ic' pointer redefinition.
ieee80211_superg.c:
superg_ioctl_set80211(): drop unreachable return.
Tested with clang 3.8.0, gcc 4.6.4 and gcc 5.3.0.
Hide subtype mask/shift (which is used for index calculation
in ieee80211_mgt_subtype_name[] array) in function call.
Tested with RTL8188CUS, STA mode.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D5369
le*dec / le*enc functions.
Replace net80211 specific macros with system-wide bytestream
encoding/decoding functions:
- LE_READ_2 -> le16dec
- LE_READ_4 -> le32dec
- LE_WRITE_2 -> le16enc
- LE_WRITE_4 -> le32enc
+ drop ieee80211_input.h include, where it was included for these
operations only.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D6030
- Add definitions for Timing Advertisement and Control Wrapper frames.
- Refresh ieee80211_mgt_subtype_name and ieee80211_ctl_subtype_name
arrays.
- Count Timing Advertisement frames as discarded management frames in all
modes.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5331
Move error handling into ieee80211_parent_xmitpkt() instead of spreading it
between functions.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3772
DragonflyBSD uses the FreeBSD wireless stack and drivers. Their malloc()
API is named differently, so they don't have userland/kernel symbol
clashes like we do (think libuinet.)
So, to make it easier for them and to port to other BSDs/other operating
systems, start hiding the malloc specific bits behind defines in
ieee80211_freebsd.h.
DragonflyBSD can now put these portability defines in their local
ieee80211_dragonflybsd.h.
This should be a great big no-op for everyone running wifi.
TODO:
* kill M_WAITOK - some platforms just don't want you to use it
* .. and/or handle it returning NULL rather than waiting forever.
* MALLOC_DEFINE() ?
* Migrate the well-known malloc names (eg M_TEMP) to net80211
namespace defines.
Smart NICs with firmware (eg wpi, iwn, the new atheros parts, the intel 7260
series, etc) support doing a lot of things in firmware. This includes but
isn't limited to things like scanning, sending probe requests and receiving
probe responses. However, net80211 doesn't know about any of this - it still
drives the whole scan/probe infrastructure itself.
In order to move towards suppoting smart NICs, the receive path needs to
know about the channel/details for each received packet. In at least
the iwn and 7260 firmware (and I believe wpi, but I haven't tried it yet)
it will do the scanning, power-save and off-channel buffering for you -
all you need to do is handle receiving beacons and probe responses on
channels that aren't what you're currently on. However the whole receive
path is peppered with ic->ic_curchan and manual scan/powersave handling.
The beacon parsing code also checks ic->ic_curchan to determine if the
received beacon is on the correct channel or not.[1]
So:
* add freq/ieee values to ieee80211_rx_stats;
* change ieee80211_parse_beacon() to accept the 'current' channel
as an argument;
* modify the iv_input() and iv_recv_mgmt() methods to include the rx_stats;
* add a new method - ieee80211_lookup_channel_rxstats() - that looks up
a channel based on the contents of ieee80211_rx_stats;
* if it exists, use it in the mgmt path to switch the current channel
(which still defaults to ic->ic_curchan) over to something determined
by rx_stats.
This is enough to kick-start scan offload support in the Intel 7260
driver that Rui/I are working on. It also is a good start for scan
offload support for a handful of existing NICs (wpi, iwn, some USB
parts) and it'll very likely dramatically improve stability/performance
there. It's not the whole thing - notably, we don't need to do powersave,
we should not scan all channels, and we should leave probe request sending
to the firmware and not do it ourselves. But, this allows for continued
development on the above features whilst actually having a somewhat
working NIC.
TODO:
* Finish tidying up how the net80211 input path works.
Right now ieee80211_input / ieee80211_input_all act as the top-level
that everything feeds into; it should change so the MIMO input routines
are those and the legacy routines are phased out.
* The band selection should be done by the driver, not by the net80211
layer.
* ieee80211_lookup_channel_rxstats() only determines 11b or 11g channels
for now - this is enough for scanning, but not 100% true in all cases.
If we ever need to handle off-channel scan support for things like
static-40MHz or static-80MHz, or turbo-G, or half/quarter rates,
then we should extend this.
[1] This is a side effect of frequency-hopping and CCK modes - you
can receive beacons when you think you're on a different channel.
In particular, CCK (which is used by the low 11b rates, eg beacons!)
is decodable from adjacent channels - just at a low SNR.
FH is a side effect of having the hardware/firmware do the frequency
hopping - it may pick up beacons transmitted from other FH networks
that are in a different phase of hopping frequencies.
frames to 0
From IEEE Std. 802.11-2012, 8.3.2.1 "Data frame format", p. 415 (513):
"The Sequence Control field for QoS (+)Null frames is ignored by the receiver
upon reception."
At this moment, any <mode>_input() function interprets them as regular QoS data
frames with TID = 0. As a result, stations, that use another TX sequence for
QoS Null frames (e.g. wpi(4), where (QoS) Null frames are generated by the
firmware), may experience significant packet loss with any other NIC in hostap
mode.
Tested:
* wpi(4) (author)
* iwn(4) - Intel 5100, STA mode (me)
PR: kern/200128
Submitted by: Andriy Voskoboinyk <s3erios@gmail.com>
results.
Right now the scan infrastructure assumes the channel is under net80211
control, and that when receiving beacon frames for scanning, the
current channel is indeed what ic_curchan is set to.
But firmware NICs with firmware scan support need more than this -
they can do background scans whilst hiding the off-channel behaviour
from net80211. Ie, net80211 still thinks everything is associated
and on the main channel, but it's getting scan results from all the
background traffic.
However sta_add() pays attention to ic_curchan and discards scan
results that aren't on the right channel. CCK beacon frames can be
decoded from adjacent channels so the receive path and sta_add
discard these as appropriate. This is fine for software scanning
like for ath(4), but not for firmware NICs. So with those, the
whole concept of background firmware scanning won't work without
major hacks (eg, overriding ic_curchan before calling the beacon
input / scan add.)
As part of my scan overhaul, modify sta_add() and the scan_add()
APIs to take an explicit current channel. The normal RX path
will set it to ic_curchan so it's a no-op. However, drivers may
decide to (eventually!) override the scan method to set the
"right" current channel based on what the firmware reports the
scan state is.
So for example, iwn, rsu and other NICs will eventually do this:
* driver issues scan start firmware command;
* firmware sends a "scan start on channel X" notify;
* firmware sends a bunch of beacon RX's as part of
the scan results;
* .. and the driver will replace scan_add() curchan with channel X,
so scan results are correct.
* firmware sends a "scan start on channel Y" notify;
* firmware sends more beacons...
* .. the driver replaces scan_add() curchan with channel Y.
Note:
* Eventually, net80211 should eventually grow the idea of a per-packet
current channel. It's possible in various modes (eg WAVE, P2P, etc)
that individual frames can come in from different channels and that
is under firmware control rather than driver/net80211 control, so
we should support that.
The origin of WEP comes from IEEE Std 802.11-1997 where it defines
whether the frame body of MAC frame has been encrypted using WEP
algorithm or not.
IEEE Std. 802.11-2007 changes WEP to Protected Frame, indicates
whether the frame is protected by a cryptographic encapsulation
algorithm.
Reviewed by: adrian, rpaulo
to this event, adding if_var.h to files that do need it. Also, include
all includes that now are included due to implicit pollution via if_var.h
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
