Falling back to the multicast key may cause unicast traffic to leak.
Instead fail when no key is found.
For more information see the 'Framing Frames: Bypassing Wi-Fi Encryption
by Manipulating Transmit Queues' paper.
[ I updated the commit message to reference the paper and the code
comment to record historic behaviour as discussed in private email. ]
Security: CVE-2022-47522
ieee80211_scan_dump_channels() is only used locally and only when
IEEE80211_DEBUG is compiled. Stop exporting it, make it file local
and hide under the #ifdef to reduce the footprint for production
kernels a tiny bit.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D38833
scan state ss_flags in two places cut off the "internal" GOTPICK
options. Replace the hardcoded 0xfff with a defined mask.
Note that "internal" flags is confusing as we also supplement the
the 16bit by another 16bit of "internal flags" passed around but
comaparing to GOTPICK never stored to my understanding.
No functional change.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D38832
As the comment says it probably does not matter but use a local
variable to track state under lock so we can return the last known
good state of what we thought we were operating under after unlocking.
Likely no functional changes.
Sponsored by: The FreeBSD Foundation
MFC atfer: 3 days
Reviewed by: enweiwu, adrian
Differential Revision: https://reviews.freebsd.org/D38660
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
In this call to IEEE80211_NOTE, ni is always NULL due to the assignment
a few lines earlier at the start of the function. If debug traces are
enabled, then this will pass an invalid pointer as the 'mac' pointer to
ieee80211_note_mac. Use IEEE80211_DPRINTF which doesn't take a 'ni'
argument instead.
Reported by: GCC -Wstringop-overread
Reviewed by: bz, emaste
Differential Revision: https://reviews.freebsd.org/D37626
* Add link-state change notifications by subscribing to ifnet_link_event.
In the Linux netlink model, link state is reported in 2 places: first is
the IFLA_OPERSTATE, which stores state per RFC2863.
The second is an IFF_LOWER_UP interface flag. As many applications rely
on the latter, reserve 1 bit from if_flags, named as IFF_NETLINK_1.
This flag is mapped to IFF_LOWER_UP in the netlink headers. This is done
to avoid making applications think this flag is actually
supported / presented in non-netlink outputs.
* Add flag change notifications, by hooking into rt_ifmsg().
In the netlink model, notification should include the bitmask for the
change flags. Update rt_ifmsg() to include such bitmask.
Differential Revision: https://reviews.freebsd.org/D37597
Remove the KPI/KBI changes from ieee80211_node.h and always use the
macros to pass in __func__ and __LINE__ to the functions.
The actual implementations are prefixed by "_" rather than suffixed
by "_debug" as they no longer are "debug"-specific.
Some of the select functions were not actually using the passed in
func, line options; however they are calling other functions which
use them. Directly call the internal implementation in those cases
passing the arguments on.
Use a file-local __debrefcnt_used define to mark the arguments __unused
in cases when we compile without IEEE80211_DEBUG_REFCNT and hope the
toolchain is intelligent enough to not pass them at all in those cases.
Also _ieee80211_free_node() now has a conflict so make the previous
_ieee80211_free_node() the new __ieee80211_free_node().
Add IEEE80211_DEBUG_REFCNT to the NOTES file on amd64 to keep exercising
the option.
Sponsored by: The FreeBSD Foundation
X-MFC: never
Discussed on: freebsd-wireless
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D37529
The IEEE80211_F_WME checks done on the ic were changed to be per-vap
back in the time when multi-bss was introduced or earlier in 2008.
This one was left out but given it is a (re-)accos-req case I see
no reason not to use the vap value here for consistency too.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D36733
Convert most of the cloner customers who require custom params
to the new if_clone KPI.
Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D36636
MFC after: 2 weeks
Fix types for various struct fields (initially added as int).
Move structs and inline functions logically together, e.g., for wowlan.
Add more skeleton functions and #defines needed for iwlwifi d3.c
in the future.
Add struct ieee80211_vht_cap (without "_ie") to net80211 and remove
duplicate definitions in LinuxKPI headers now using net80211 structs.
For now leave ieee80211_ie_vhtcap in net80211. I am not sure yet if we
actually need it as such. That'll be cleaned up with more VHT updates
in net80211 in the future.
No functional changes in currently compiled code intended.
Try to implement ieee80211_action_contains_tpc() as I ran into it with
an older iwlwifi chipset. This depends on c994352a88.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Update to the full list of action field category values based on
802.11-2020 with 11ax extensions and remove one value Reserved nowadays.
While here annotate them with descriptions.
Also add Spectrum Management and Radio Measurement action field values
needed in LinuxKPI.
No functional changes.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Update to the full list of frame type and subtype values based on
802.11-2020 with 11ax and 11ay extensions. This includes the 4th type
"Extension" (IEEE80211_FC0_TYPE_EXT).
While here annotate them with descriptions which should help matching
names (as at times things get confusing with LinuxKPI).
Also remove some 802.11-1997 values Reserved nowadays.
No functional changes.
Sponsored by: The FreeBSD Foundation
MFC after: 5 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D36410
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
I got lost in the #ifdef #endif here so I changed the code to a
switch block with two non-overlapping #ifdef parts and a default
which makes it a lot easier to read.
No functional changes.
Sponsored by: The FreeBSD Foundation
Reviewed by: (zlei.huang gmail.com)
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D36411
o Statically initialize max_linkhdr to default value without relying
on domain(9) code doing that.
o Statically initialize max_protohdr to a sane value, without relying
on TCP being always compiled in.
o Retire max_datalen. Set, but not used.
o Don't make the domain(9) system responsible in validating these
values and updating max_hdr. Instead provide KPI max_linkhdr_grow()
and max_protohdr_grow().
o Call max_linkhdr_grow() from IEEE802.11 and max_protohdr_grow() from
TCP. Those are the only protocols today that may want to grow.
Reviewed by: tuexen
Differential revision: https://reviews.freebsd.org/D36376
Rather than defining the same values in two places and having to do
conflict resulution on the name in LKPI, change the defines to an
enum in net80211. In addition to de-duplication this also gives us
value checks in certain cases.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D36250
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
Make sure the given IE length fits into the total length left when
parsing through the information elements. In theory I would say
discard everything if there is an error but that proves hard with
the current code.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D36245
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
When printing the current state name and the old state numeric value,
both are always the same. Remove the redundant ostate. It is always
the same as iv_state.
Reviewed by: bz
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D35849
While 80P80 is less likely to be used, VHT160 (a single contiguous
width) is harder to acquire but also preferable so return that first.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D35977
In ieee80211_vht_adjust_channel() we have to check for all possible
IEEE80211_FVHT_VHT* options using the mask rather than just checking
for IEEE80211_FVHT_VHT; ieee80211_vhtchanflags() (contrary to its
HT counterpart) only returns the "highest" flag nor or-ing them together
with the base flag. For the moment this seems to make sense as with
more width options we'd add a pyramid.
Later on, in the same function when we get VHT160 actually go and look
for VHT160 and not VHT80.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D35977
Add the fields for VHT (2Ghz and 5Ghz) to report back by media_status
so we actually have a chance to get the right information.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D35977
Start adding more fields to DDB output related to VHT (11ac) and
mark COM, VAP, and STA more explicitly to make show all vaps /..
more readable.
Sponsored by: The FreeBSD Foundaton
MFC after: 1 week
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D35977
Correct IEEE80211_FEXT_BITS adding the missed one and move the later
one further. This will actually make VHT to show.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D35977
Add more Element IDs for VHT (11ac) to complete the current list
and we can use them if/as needed.
Sposnored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D35977
With clang 15, the following -Werror warning is produced:
sys/net80211/ieee80211_proto.c:1070:34: error: variable 'num_mixed' set but not used [-Werror,-Wunused-but-set-variable]
int num_vaps = 0, num_pure = 0, num_mixed = 0;
^
The 'num_mixed' variable was in ieee80211_proto.c when the function
vap_update_ht_protmode() was added, but it was never used for anything,
so remove it.
MFC after: 3 days
802.11i-2004 did not specify that RSN can be added to the probereq,
only to the proberesp (and others) yet it was added in what seems was
b032f27c36 (multi-BSS support).
802.11-2020 does not list the IE either for probereq so remove it.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Okayed by: adrian
Differential Revision: https://reviews.freebsd.org/D34893
Combine the comment and double-unsetting of OACTIVE into a single case
after e8de31cace.
This saves the question of why we do it twice--once right before and
one more time right after the state change check.
Also move the XXX comment about kicking the queue up to where it seems
better suited now.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D35135
This took an embarrasingly long time to find.
The state changes for a radio with a STA /and/ AP VAP gets a bit messy.
The AP maps are marked as waiting, waiting for the STA AP to find a
channel to use before the AP VAPs become active.
However, the code path that clears the OACTIVE flag on a VAP only runs
during a successful run of ieee80211_newstate_cb().
So here is how it goes:
* the STA VAP goes down and needs to scan;
* the AP vap goes RUN->INIT; but it doesn't YET call ieee80211_newstate_cb();
* meanwhile - a send on the AP VAP causes the VAP to set the OACTIVE flag here;
* then the STA VAP finishes scan and goes to RUN;
* which will call wakeupwaiting() as part of the STA VAP transition to RUN;
* .. then the AP VAP goes INIT->RUN directly via a call to hostap_newstate
in wakeupwaiting rather than it being through the deferred path;
* /then/ the ieee80211_newstate_cb() is called, but it sees the state go
RUN->RUN;
* .. which results in the OACTIVE flag never being cleared.
This clears the OACTIVE flag when a VAP transitions RUN->RUN; the
driver layer or net80211 layer can set it if required in a subsequent
transmit.
Differential Revision: https://reviews.freebsd.org/D34920
Reviewed by: bz
Following up on fb8c87b4f3, which was
supposed to go into all supported branches, increase ieee80211_scanparams
status field from 8bit to 32bit (enum size) and add a dedicated error
code for Mesh ID.
Sponsored by: The FreeBSD Foundation
Introduce (*iv_update_bss)() with a default implementation to allow
drivers to overload/intercept the time when we swap iv_bss.
This helps firmware based drivers to synchronize state with firmware.
Otherwise, for some state changes, we begin with one ni (and in
LinuxKPI lsta) and try to finish with another ni (and a new lsta
in different state) and may no longer have access to the previous state.
This also saves us from constantly checking for ni changes complicating
code.
No functional changes intended.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
X-MFC: move (*iv_update_bss) to spare area
When forcing DEUATH in ieee80211_sta_join1() log the current state
we are coming from as well. Note this isn't always the state we
are expecting as iv_state was updated already, so contrary to the
comment we usually do not see RUN there.
Leave a comment earlier with regards to this as well.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Add maxchans to the disabled debugging in addchan() and copychan_prev()
to aid debugging possible errors rreturned due to reaching maxchans
limits.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Printing %p does not need the 0x prefix and while here mark the
ieee80211_node_table argument unused given we do not need it in the
current incarnation of the function.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Throughout net80211 there are multiple ways to log (debugging)
information. Start to clenaup one as I kept hitting it to harmonize
the output. The more we get away from printfs into either wrapper
functions or macros the more likely we can use holistic systematic
tracing in the future.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Add more STATE / DEBUG probes and enhance the output of one in order
to track state changes triggered by "ack" (or not).
This helped to narrow down causes from drivers or the LinuxKPI 802.11
compat framework which kept us in a scan -> auth -> scan loop.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Making use of the debug output was hard given debug lines were run in
parts through vlog (if_printf) and in (multiple) parts through printf(s).
Like some of the functions alreay have, use a local buffer to format
the string and then use a single if_printf; in addition given these
functions are debug-only, add an extra printf in case we find our
buffers still to be too small so we can adjust for the future.
We already found that 128 characters are to short for some log messages.
Bump the buffer sizes collectively to 256 characters which also is
the maximum of if_vlog() so getting longer would need further changes
elsewhere.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
We are printing %p in _db_show_sta(), there is no need to prefix it
with 0x again to get a 0x0x...
Spsonsored by: The FreeBSD Foundation
MFC after: 3 days
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
Add a void *ni_drv_data field to struct ieee80211_node that drivers
can use to backtrack to their internal state from a net80211 node.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
X-Differential Revision: https://reviews.freebsd.org/D30654 (abandoned)
Correct input_sta "assertion" checks. CTS/ACK CTRL frames are shorter
then sizeof(struct ieee80211_frame_min) and were thus running into the
is_rx_tooshort error case.
Use ieee80211_anyhdrsize() to handle this better but make sure we do
at least have the first 2 octets needed for that.
While here move the safety checks before any code which may not obey
them later, just for good style.
The non-scanning check further down assumes a frame format also not
matching control frames. For now skip the checks for control frames
which allows us to deal with some of them at least now.
Sponsored by: The FreeBSD Foundation
Obtained from: 20210906 wireless v0.91 code drop
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D32238
While IEEE80211_R_BAND was defined, there was no place to store the
band. Add a field for that, adjust ieee80211_lookup_channel_rxstatus()
to require it, and update drivers passing "R_{FREQ|IEEE}" in already to
provide the band as well. For the moment keep the fall-back code
requiring all three fields.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D30662
In 526370fb85 "net80211: proper ssid
length check in setmlme_assoc_adhoc()" we are checking the
sizeof on an array function parameter which leads to a warning that
it will resturn the size of the type of the array rather than the
array size itself. Use the defined length used both in the ioctl
and the sizing of the array function parameter instead.
Reported by: CI
MFC after: 3 days
X-MFC with: 526370fb85
In ieee80211_ies_expand() we are looping over Elements
(also known as Information Elements or IEs).
The comment suggests that we assume well-formedness of
the IEs themselves.
Checking the buffer length being least 2 (1 byte Element ID and
1 byte Length fields) rather than just 1 before accessing ie[1]
is still good practise and can prevent and out-of-bounds read in
case the input is not behaving according to the comment.
Reported by: (coypu sdf.org)
admbugs: 857
MFC after: 3 days
Reviewed by: adrian, markj
Differential Revision: https://reviews.freebsd.org/D32340
A user supplied SSID length is used without proper checks in
setmlme_assoc_adhoc() which can lead to copies beyond the end
of the user supplied buffer.
The ssid is a fixed size array for the ioctl and the argument
to setmlme_assoc_adhoc().
In addition to an ssid_len check of 0 also error in case the
ssid_len is larger than the size of the ssid array to prevent
problems.
PR: 254737
Reported by: Tommaso (cutesmilee.research protonmail.com)
MFC after: 3 days
Reviewed by: emaste, adrian
Differential Revision: https://reviews.freebsd.org/D32341
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
While debugging is very good in net80211, some log messages are
repeated in multiple places 1:1. In order to distinguish where the
discard happened and to speed up analysis, add __func__:__LINE__
information to all these messages.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
These ones were unambiguous cases where the Foundation was the only
listed copyright holder (in the associated license block).
Sponsored by: The FreeBSD Foundation
c338cf2c6d split up ieee80211_probereq_ie().
For HW scans we usually do not want to add a SSID to the IEs.
During that split we allocate memory based on the length which will
always include the length of the SSID and only later we reduced the
length but never updated the value passed back to the caller.
Split the SSID handling up and reduce the length before malloc().
This not only makes us not over-allocate in these situatoins but also
fixes the length returned to the caller and with that usually directly
passed to firmware.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D30813
Add more raditap definitions based on "names" found in actual drivers
and based on documentation from radiotap.org (where avail).
Leave one specific "duplicate" in the LinuxKPI implementation but
otherwise manage it all in net80211.
Sponsored by: The FreeBSD Foundation
MFC after: 10 days
Reviewed by: hselasky, adrian, sam
Differential Revision: https://reviews.freebsd.org/D30641
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
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
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")
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")
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")
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
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
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
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
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
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
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
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
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")
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
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
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
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
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
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.
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.
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
