#
95ee2897 |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: two-line .h pattern Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
#
4d846d26 |
|
10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD 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
|
#
f024bdf1 |
|
06-Jun-2021 |
Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be> |
net80211: mitigation against A-MSDU design flaw 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
|
#
11572d7d |
|
06-Jun-2021 |
Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be> |
net80211: reject mixed plaintext/encrypted fragments 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
|
#
49c220b0 |
|
04-Sep-2021 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
net80211: comments and whitespace Add a missing '.', fix spelling of "failed" and unwrap a closing ); No functional changes. Sponsored by: The FreeBSD Foundation MFC after: 3 days
|
#
e9efad4f |
|
13-Jun-2020 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] Treat frames without an rx status as not a decap'ed A-MSDU. Drivers for NICs which do A-MSDU decap in hardware / driver will need to set the rx status, so if it's missing then treat it as not a decap'ed A-MSDU.
|
#
fe267a55 |
|
27-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
sys: general adoption of SPDX licensing ID tags. 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.
|
#
79caf56e |
|
13-Oct-2017 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] don't try to follow a NULL rxs pointer down the sink. It's smelly, and we already checked earlier whether we needed to.
|
#
48f95a36 |
|
12-Oct-2017 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] begin handling multiple hardware decap'ed A-MSDU in the RX path. The duplicate detection code currently expects A-MSDU frames to be encaped - they're decap'ed /after/ duplicate detection. However for ath10k (and iwm hardware later on) the firmware supports doing A-MSDU decap in hardware - which shows up as multiple frames with the same sequence number and IV. This is the first part of decap handling - if we see a stretch of A-MSDU frames from the driver with the MORE bit set, then don't treat them as duplicates. This isn't 100% complete as crypto sequence number handling and "A-MSDU in A-MPDU" needs handling, but it's a start. This should be a glorified no-op for everyone. Please tell me if it isn't.
|
#
85c4e670 |
|
19-May-2017 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] prepare for A-MSDU/A-MPDU offload crypto / sequence number checking. 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!
|
#
9764ef21 |
|
29-Jan-2017 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] address seqno allocation for group addressed frames After some digging and looking at packet traces, it looks like the sequence number allocation being done by net80211 doesn't meet 802.11-2012. Specifically, group addressed frames (broadcast, multicast) have sequence numbers allocated from a separate pool, even if they're QoS frames. This patch starts to try and address this, both on transmit and receive. * When receiving, don't throw away multicast frames for now. It's sub-optimal, but until we correctly track group addressed frames via another TID counter, this is the best we can do. * When doing A-MPDU checks, don't include group addressed frames in the sequence number checks. * When transmitting, don't allocate group frame sequence numbers from the TID, instead use the NONQOS TID for allocation. This may fix iwn(4) 11n because I /think/ this was one of the handful of places where ni_txseqs[] was being assigned /outside/ of the driver itself. This however doesn't completely fix things - notably the way that TID assignment versus WME assignment for driver hardware queues will mess up multicast ordering. For example, if all multicast QoS frames come from one sequence number space but they're expected to obey the QoS value assigned, they'll end up in different queues in the hardware and go out in different orders. I can't fix that right now and indeed fixing it will require some pretty heavy lifting of both the WME<->TID QoS assignment, as well as figuring out what the correct way for drivers to behave. For example, both iwn(4) and ath(4) shouldn't put QoS multicast traffic into the same output queue as aggregate traffic, because the sequence numbers are all wrong. So perhaps the correct thing to do there is ignore the WME/TID for QoS traffic and map it all to the best effort queue or something, and ensure it doesn't muck up the TID/blockack window tracking. However, I'm /pretty/ sure that is still going to happen. .. maybe I should disable multicast QoS frames in general as well, but I don't know what that'll do for whatever the current state of 802.11s mesh support is. Tested: * STA mode, ath10k NIC * AP mode, AR9344/AR9580 AP * iperf tcp/udp tests with concurrent multicast QoS traffic. Before this, iperfs would fail pretty quickly because the sending AP would start sending out QoS multicast frames that would be out of order from the rest of the TID traffic, causing the blockack window to get way, way out of sync. This now doesn't occur. TODO: * verify which QoS frames SHOULD be tagged as M_AMPDU_MPDU. For example, QoS NULL frames shouldn't be tagged! Reviewed by: avos Differential Revision: https://reviews.freebsd.org/D9357
|
#
4357a5d1 |
|
20-Apr-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211: hide subtype mask & shift in function call. 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
|
#
31021a2b |
|
20-Apr-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211: replace internal LE_READ_*/LE_WRITE_* macro with system 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
|
#
1ffa8d7e |
|
29-Feb-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211: eliminate copy-paste nearby ieee80211_check_rxseq() Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D4043
|
#
c79f192c |
|
25-May-2015 |
Adrian Chadd <adrian@FreeBSD.org> |
Begin plumbing ieee80211_rx_stats through the receive path. 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.
|
#
c3ebe019 |
|
12-May-2015 |
Adrian Chadd <adrian@FreeBSD.org> |
Do not check sequence number for QoS Null frames; set it for generated QoS Null 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>
|
#
cd0b8f2d |
|
03-May-2011 |
Adrian Chadd <adrian@FreeBSD.org> |
Fix some corner cases in the net80211 sequence number retransmission handling. The current sequence number code does a few things incorrectly: * It didn't try eliminating duplications from HT nodes. I guess it's assumed that out of order / retransmission handling would be handled by the AMPDU RX routines. If a HT node isn't doing AMPDU RX, then retransmissions need to be eliminated. Since most of my debugging is based on this (as AMPDU TX software packet aggregation isn't yet handled), handle this corner case. * When a sequence number of 4095 was received, any subsequent sequence number is going to be (by definition) less than 4095. So if the following sequence number (0) doesn't initially occur and the retransmit is received, it's incorrectly eliminated by the IEEE80211_FC1_RETRY && SEQ_LEQ() check. Try to handle this better. This almost completely eliminates out of order TCP statistics showing up during iperf testing for the 11a, 11g and non-aggregate 11n AMPDU RX case. The only other packet loss conditions leading to this are due to baseband resets or heavy interference.
|
#
a7d5f7eb |
|
19-Oct-2010 |
Jamie Gritton <jamie@FreeBSD.org> |
A new jail(8) with a configuration file, to replace the work currently done by /etc/rc.d/jail.
|
#
519f677a |
|
18-Jul-2009 |
Sam Leffler <sam@FreeBSD.org> |
Move code that does payload realigment to a new routine, ieee80211_realign, so it can be reused. While here rewrite the logic to always use a single mbuf. Reviewed by: rpaulo Approved by: re (kib)
|
#
616190d0 |
|
24-Mar-2009 |
Sam Leffler <sam@FreeBSD.org> |
split Atheros SuperG support out into it's own file that's included only with a new IEEE80211_SUPPORT_SUPERG option
|
#
10ad9a77 |
|
08-Jan-2009 |
Sam Leffler <sam@FreeBSD.org> |
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
|
#
d7f03759 |
|
19-Oct-2008 |
Ulf Lilleengen <lulf@FreeBSD.org> |
- Import the HEAD csup code which is the basis for the cvsmode work.
|
#
b032f27c |
|
20-Apr-2008 |
Sam Leffler <sam@FreeBSD.org> |
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
|