Prevents build errors by ensuring that it is only selected when a wext based
driver that needs it is also selected
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Serge Vasilugin reports:
To improve mt7620 built-in wifi performance some changes:
1. Correct BW20/BW40 switching (see comments with mark (1))
2. Correct TX_SW_CFG1 MAC reg from v3 of vendor driver see
https://gitlab.com/dm38/padavan-ng/-/blob/master/trunk/proprietary/rt_wifi/rtpci/3.0.X.X/mt76x2/chips/rt6352.c#L531
3. Set bbp66 for all chains.
4. US_CYC_CNT init based on Programming guide, default value was 33 (pci),
set chipset bus clock with fallback to cpu clock/3.
5. Don't overwrite default values for mt7620.
6. Correct some typos.
7. Add support for external LNA:
a) RF and BBP regs never be corrected for this mode
b) eLNA is driven the same way as ePA with mt7620's pin PA
but vendor driver explicitly pin PA to gpio mode (for forrect calibration?)
so I'm not sure that request for pa_pin in dts-file will be enough
First 5 changes (really 2) improve performance for boards w/o eLNA/ePA.
Changes 7 add support for eLNA
Configuration w/o eLAN/ePA and with eLNA show results
tx/rx (from router point of view) for each stream:
35-40/30-35 Mbps for HT20
65-70/60-65 Mbps for HT40
Yes. Max results for 2T2R client is 140-145/135-140
with peaks 160/150, It correspond to mediatek driver results.
Boards with ePA untested.
Reported-by: Serge Vasilugin <vasilugin@yandex.ru>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Prepare patches for sending upstream by adding patch descriptions
generated from the original OpenWrt commits adding each patch.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
It is common for 802.11ax NICs to support more than just AP mode, which
results in there being a distinct set of HE capabilities for each mode. As
(bad) luck would have it, iw prints out info for each HE mode in sequential
order according to `enum nl80211_iftype`, and AP mode isn't always first.
As a result, the wrong set of HE capabilities can be parsed if an AP NIC
supports station (managed) mode or any other mode preceding AP mode, since
only the first set of HE capabilities printed by iw is parsed from awk's
output.
This has a noticeable impact on beamforming for example, since managed mode
usually doesn't have beamformer capabilities enabled, while AP mode does.
Hostapd won't be set up with the configs to enable beamformer capabilities
in this scenario, causing hostapd to disable beamforming to HE stations
even when it's supported by the AP.
Always parse the correct set of HE capabilities for AP mode to fix this.
This is achieved by trimming all of iw's output prior to the AP mode
capabilities, which ensures that the first set of HE capabilities are
always for AP mode.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Add support for randomly generating a MAC address for a wifi-iface
instance by setting `macaddr` to `random`
When set to `random`, a new locally administered unicast MAC address
is generated and assigned to the iface everytime it is (re-)configured
Signed-off-by: Manas Sambhus <manas.sambhus+github@gmail.com>
Backports upstream fix from 5.19
lockdep complains use of uninitialized spinlock at ieee80211_do_stop() [1],
for commit f856373e2f31ffd3 ("wifi: mac80211: do not wake queues on a vif
that is being stopped") guards clear_bit() using fq.lock even before
fq_init() from ieee80211_txq_setup_flows() initializes this spinlock.
According to discussion [2], Toke was not happy with expanding usage of
fq.lock. Since __ieee80211_wake_txqs() is called under RCU read lock, we
can instead use synchronize_rcu() for flushing ieee80211_wake_txqs().
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
This updates mac80211 to version 5.15.58-1 which is based on kernel
5.15.58.
The removed patches were applied upstream.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
TechNexion PICO-PI-IMX7D uses BCM4339 Wi-Fi interface in SDIO mode.
Enable SDIO support for imx/cortexa7 to fully support it in images.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
The mac80211-hwsim and the Intel iwlwifi driver support ieee80211ax, add
the missing DRIVER_11AX_SUPPORT dependency too.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
In Turris MOX SDIO card [1], which uses Marvell 88W997 and its driver
mwifiex, you might get cryptic messages, which are not helpful to use.
@pali created patch, which improves messages by the driver and he will
send this to Linux kernel soon.
Before:
[ 81.026156] mwifiex_sdio mmc1:0001:1: CMD_RESP: cmd 0x20 error, result=0x1
After:
[ 15.784018] mwifiex_sdio mmc1:0001:1: CMD_RESP: cmd RF_ANTENNA (0x20) error, result=0x1
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
SDIO chip 88W9997 from NXP [1] is quite limited by its firmware and
driver. Add hacky patch to allow up to 4 SSID instead of 3 SSID.
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Introduce a new option background_radar to toggle hostapd's background
radar feature. Enabling this allows DFS CAC to run on dedicated radio RF
chains while the radio(s) are otherwise running normal AP activities on
other channels.
As OpenWrt configures hostapd to use a channel list even when a single
channel is configured, using this feature requires a list of channels in
/etc/config/wireless. Alternatively, channel can be set to auto.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Acked-by: David Bauer <mail@david-bauer.net>
Enable ath10k offload by default. This improves wireless performance
without requiring user configuration.
This adds ath10k_core to the AUTOLOAD section so that the frame_mode
paramter can be added to /etc/modules.d and passed to the driver.
The frame_mode 2 enables ethernet mode on the firmware/driver.
This parameter is set by passing a different value to the frame_mode
value on kmod insmod.
Link to the original patchset:
https://patchwork.kernel.org/project/linux-wireless/cover/20220516032519.29831-1-ryazanov.s.a@gmail.com/
Signed-off-by: Tiago Gaspar <tiagogaspar8@gmail.com>
This reverts the airtime scheduler back from the virtual-time based scheduler
to the deficit round robin scheduler implementation.
This reduces burstiness and improves fairness by improving interaction with AQL.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The MAC can be stored in OTP memory or in flash memory, currently the
driver could read it only from OTP. Backport the patch allowing setting
the MAC address from flash. Some modules have the OTP programmed but
the ODM/OEM decided to overwrite it with value stored in flash.
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
This backports encap offload support from upstream.
On some ath10k devices there can be about 10% improvement on tx throughput.
Users can turn it on by setting frame_mode=2.
Signed-off-by: Zhijun You <hujy652@gmail.com>
Sync nl80211.h with upstream in order to maintain parity with
nl80211_copy.h shipped with hostapd.
This is necessary, as currently the enum value for
NL80211_EXT_FEATURE_RADAR_BACKGROUND mismatches between hostapd and
mac80211. This breaks background radar capability detection in hostapd.
Reported-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: David Bauer <mail@david-bauer.net>
In case no specific BSS color is configured, set it to a random value.
Signed-off-by: David Bauer <mail@david-bauer.net>
Tested-by: Stijn Tintel <stijn@linux-ipv6.be>
latency and short-term fairness is improved by fixing the tx queue sorting
so that it considers the pending AQL budget
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Add ieee80211_rx_check_bss_color_collision routine in order to introduce
BSS color collision detection in mac80211 if it is not supported in HW/FW
(e.g. for mt7915 chipset).
Add IEEE80211_HW_DETECTS_COLOR_COLLISION flag to let the driver notify
BSS color collision detection is supported in HW/FW. Set this for ath11k
which apparently didn't need this code.
Tested-by: Peter Chiu <Chui-Hao.Chiu@mediatek.com>
Co-developed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/a05eeeb1841a84560dc5aaec77894fcb69a54f27.1648204871.git.lorenzo@kernel.org
[clarify commit message a bit, move flag to mac80211]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David Bauer <mail@david-bauer.net>
Some ath10k IPQ40xx devices like the MikroTik hAP ac2 and ac3 require the
BDF-s to be extracted from the device storage instead of shipping packaged
API 2 BDF-s.
This is required as MikroTik has started shipping boards that require BDF-s
to be updated, as otherwise their WLAN performance really suffers.
This is however impossible as the devices that require this are release under
the same revision and its not possible to differentiate them from devices
using the older BDF-s.
In OpenWrt we are extracting the calibration data during runtime and we are
able to extract the BDF-s in the same manner, however we cannot package the
BDF-s to API 2 format on the fly and can only use API 1 to provide BDF-s on
the fly.
This is an issue as the ath10k driver explicitly looks only for the board.bin
file and not for something like board-bus-device.bin like it does for pre-cal
data.
Due to this we have no way of providing correct BDF-s on the fly, so lets
extend the ath10k driver to first look for BDF-s in the board-bus-device.bin
format, for example: board-ahb-a800000.wifi.bin
If that fails, look for the default board file name as defined previously.
So, backport the upstream ath10k patch.
Signed-off-by: Robert Marko <robimarko@gmail.com>
This reverts commit f9ff282d17 as during
upstream patch review process nbd pointed out, that this patch needs
more work:
"The patch looks wrong to me. I'm pretty sure that AR_CH0_TOP2 is the
correct register, the definition has an explicit check for 9561 as well.
I believe this patch works by accident because it avoids writing a wrong
value to that register."
1. https://lore.kernel.org/all/91c58969-c60e-2f41-00ac-737786d435ae@nbd.name
Signed-off-by: Petr Štetiar <ynezz@true.cz>
ath9k is setting the TX PA DC bias level different on QCA9561 and QCA9565
although they have the same radio IP-core, which results in a very low
output power and very low throughput as devices are further away from
the AP (compared to other 2.4GHz APs.)
In real life testing, without this patch the 2.4GHz throughput on Yuncore
XD3200 is around 10Mbps sitting close to the AP, and close to theoretical
maximum with the patch applied.
Signed-off-by: Clemens Hopfer <openwrt@wireloss.net>
[edit commit message]
Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
This updates mac80211 to version 5.15.33-1 which is based on kernel
5.15.33.
The removed patches were applied upstream.
This new release contains many fixes which were merged into the upstream
Linux kernel.
This also contains the following new drivers which are needed for ath11k:
* net/qrtr/
* drivers/bus/mhi/
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
LOCK_STATE_HELD define was omitted during backport of
lockdep_assert_not_held() which leads to build failures of kernels with
CONFIG_LOCKDEP=y:
backports-5.15.8-1/backport-include/linux/lockdep.h:16:47: error: 'LOCK_STATE_HELD' undeclared (first use in this function)
Fix it by adding missing LOCK_STATE_HELD define.
References: PR#9373
Reported-by: Oskari Rauta <oskari.rauta@gmail.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Both struct net_device_path_ctx and struct net_device_path
are not available in 5.4. This causes an build error on the
bcm63xx target.
|mac80211/driver-ops.h: In function 'drv_net_fill_forward_path':
|driver-ops.h:1502:57: error: passing argument 4 of
|'local->ops->net_fill_forward_path' from incompatible pointer type
| [-Werror=incompatible-pointer-types]
| 1502 | ctx, path);
| | ^~~
| | |
| | struct net_device_path_ctx *
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
This commit adds the following package compile options.
CONFIG_PACKAGE_RTW88_DEBGUG:
Compile the driver with additional debug logging output
CONFIG_PACKAGE_RTW88_DEBGUGFS:
Add the possibility to map information about the driver rtw88 into
debugfs.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Based on: 1ac627024d ("kernel: ath10k-ct: provide a build variant for
small RAM devices")
Like described in the ath10k-ct-smallbuffers version, oom-killer gets
triggered frequently by devices with small RAM.
That change is necessary for many community mesh networks which use
ath10k based devices with too little RAM. The -ct driver has been
proven unstable if used with 11s meshing and only wave2 chipsets are
supporting 11s. Freifunk Berlin is nowadays assembling its
firmware-based completely of vanilla OpenWRT with some package additions
which are made through the imagebuilder. Therefore we cannot take the
approach other freifunk communities have taken to maintain that patch
downstream [1]. Other communities consider these devices as broken and
that change would pretty much give those devices a second life [2].
[1] - 450b306e54
[2] - https://github.com/freifunk-gluon/gluon/issues/1988#issuecomment-619532909
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Signed-off-by: Nick Hainke <vincent@systemli.org>
The following patches were backported from upstream before and are not
needed any more:
package/kernel/mac80211/patches/ath10k/081-ath10k-fix-module-load-regression-with-iram-recovery-feature.patch
package/kernel/mac80211/patches/ath10k/980-ath10k-fix-max-antenna-gain-unit.patch
package/kernel/mac80211/patches/build/010-headers-Add-devm_platform_get_and_ioremap_resource.patch
package/kernel/mac80211/patches/subsys/300-mac80211-drop-check-for-DONT_REORDER-in-__ieee80211_.patch
package/kernel/mac80211/patches/subsys/307-mac80211-do-not-access-the-IV-when-it-was-stripped.patch
package/kernel/mac80211/patches/subsys/308-mac80211-fix-radiotap-header-generation.patch
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
When compiling with CONFIG_USE_RFKILL=y, the build fails and mentions that
dependency on kmod-rfkill is missing, which is correct [1]. Add this
dependency to the Makefile.
Depend on +USE_RFKILL and not PACKAGE_kmod-rfkill, because it forces
selection of kmod-rfkill package. Other combinations in DEPENDS like
USE_RFKILL:kmod-rfkill or (+)PACKAGE_kmod-rfkill:kmod-rfkill do not force
selection of kmod-rfkill package.
The kmod-rfkill package itself depends on USE_RFKILL, so with +USE_RFKILL
in kmod-cfg80211 package it is not possible to select wrong combination of
packages.
[1] https://linux-wireless.vger.kernel.narkive.com/m8JY9Iks/cfg80211-depends-on-rfkill-or-not
Signed-off-by: Oldřich Jedlička <oldium.pro@gmail.com>
Some drivers that do their own sequence number allocation (e.g. ath9k, mwlwifi) rely
on being able to modify params->ssn on starting tx ampdu sessions.
This was broken by a change that modified it to use sta->tid_seq[tid] instead.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
On systems using brmcfmac (e.g. Raspberry Pi Zero W) without this fix,
the final setup-call:
iw dev wlan0 ibss join ...
fails with returncode 161 and message:
"command failed: Not supported (-95)"
So this patch calls an explicit:
iw dev wlan0 set type ibss
just prior to the 'ibss join' command.
I have tested several ath9k and mt76xx devices
with different revisions: this patch does not harm.
please also apply to stable branch.
Signed-off-by: Bastian Bittorf <bb@npl.de>
The nl80211_set_wiphy() function was changed between kernel 5.11 and
5.12 to take the rdev->wiphy lock which should be freed at the end
again. The 500-mac80211_configure_antenna_gain.patch added some code
which just returned in some cases without unlocking. This resulted in a
deadlock with brcmfmac.
This patch fixes this by also jumping to the out label in case we want
to leave the function.
This fixes a hanging system when brcmfmac is in use. I do not know why
we do not see this with other driver.
The kernel returns very useful debug details when setting these OpenWrt
configuration options:
CONFIG_KERNEL_DETECT_HUNG_TASK=y
CONFIG_KERNEL_PROVE_LOCKING=y
Fixes: FS#4122
Fixes: b96c2569ac ("mac80211: Update to version 5.12.19-1")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
When __ieee80211_select_queue is called, skb->cb has not been cleared yet,
which means that info->control.flags can contain garbage.
In some cases this leads to IEEE80211_TX_CTRL_DONT_REORDER being set, causing
packets marked for other queues to randomly end up in BE instead.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
With "getting WIFI MAC from NVMEM" working on ath79 on 5.10,
the next logical step I think is to utilize nvmem subsystem
to also get the calibration data from there.
This will tremendously speed up the wifi bring-up, since
we no longer need the userspace helper for the simple
devices that can just load them from there.
included with this patch is a package/mac80211/refresh.
Tested on: WNDR3700v2, TP-Link Archer C7v2
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Backport upstream fix for module load regression caused by IRAM recovery.
Without this patch devices using mainline ath10k driver could lost wireless
function because ath10k module failed to load.
Signed-off-by: Zhijun You <hujy652@gmail.com>
OpenWrt maintains two special out-of-tree DT properties:
"qca,disable-5ghz" and "qca,disable-2ghz". These are implemented
in a mac80211 ath9k patch "550-ath9k-disable-bands-via-dt.patch".
With the things being what they are, now might be a good
point to switch the devices to the generic and upstream
"ieee80211-freq-limit" property. This property is much
broader and works differently. Instead of disabling the
drivers logic which would add the affected band and
channels. It now disables all channels which are not
within the specified frequency range.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> # HH5A
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
This function is missing in kernel 5.4, but it is sued by ath10k.
This fixes the build of ath10k on some targets.
Fixes: cfe0eb7485 ("mac80211: Update to version 5.14.13-1")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The removed patches were applied upstream.
The Cisco Aironet 802.11b driver was removed from backports, remove
it also from OpenWrt.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The removed patches were applied upstream.
of_get_mac_address() was backported in our OpenWrt kernel, remove the
change from backports.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The removed patches were applied upstream.
This backports version 5.11.22 and later does not support kernel
versions < 4.4, this allows us to remove some patches too.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
In the current state, nvmem cells are only detected on platform device.
To quickly fix the problem, we register the affected problematic driver
with the of_platform but that is more an hack than a real solution.
Backport from net-next the required patch so that nvmem can work also
with non-platform devices and rework our current patch.
Drop the mediatek and dsa workaround and rework the ath10k patches.
Rework every driver that use the of_get_mac_address api.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
of_platform_device_create require CONFIG_OF selected.
Add an ifdef and register to the of platform only if of is available.
Fixes: 985954ccbd ("kernel: add ath10k support for of_get_mac_address")
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
ath10k doesn't currently support the standard function to get mac-address from the dts.
Add this for both ath10k and ath10k-ct
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
drv_mac80211_teardown fails silently if the device to be torn down is
not defined. This commit prints an error message.
branches affected: trunk, 21.02
Signed-off-by: Bob Cantor <coxede6557@w3boats.com>
When wifi is turned off, drv_mac80211_teardown sometimes fails (silently)
because the device to be torn down is not defined.
This situation arises if drv_mac80211_setup was called twice when
wifi was turned on.
This commit ensures that the device to be torn down is always defined
in drv_mac80211_teardown.
Steps to reproduce:
1) Use /sbin/wifi to turn on wifi.
uci set wireless.@wifi-iface[0].disabled=0
uci set wireless.@wifi-device[0].disabled=0
uci commit
wifi
2) Use /sbin/wifi to turn off wifi.
uci set wireless.@wifi-device[0].disabled=1
uci commit
wifi
3) Observe that wifi is still up.
branches affected: trunk, 21.02
Signed-off-by: Bob Cantor <coxede6557@w3boats.com>
If drv_mac80211_setup is called twice with the same wifi configuration,
then the second call returns early with error HOSTAPD_START_FAILED.
(wifi works nevertheless, despite the fact that setup is incomplete. But
"ubus call network.wireless status" erroneously reports that radio0 is down.)
The relevant part of drv_mac80211_setup is,
if [ "$no_reload" != "0" ]; then
add_ap=1
ubus wait_for hostapd
local hostapd_res="$(ubus call hostapd config_add "{\"iface\":\"$primary_ap\", \"config\":\"${hostapd_conf_file}\"}")"
ret="$?"
[ "$ret" != 0 -o -z "$hostapd_res" ] && {
wireless_setup_failed HOSTAPD_START_FAILED
return
}
wireless_add_process "$(jsonfilter -s "$hostapd_res" -l 1 -e @.pid)" "/usr/sbin/hostapd" 1 1
fi
This commit sets no_reload = 0 during the second call of drv_mac80211_setup.
It is perhaps worth providing a way to reproduce the situation
where drv_mac80211_setup is called twice.
When /sbin/wifi is used to turn on wifi,
uci set wireless.@wifi-iface[0].disabled=0
uci set wireless.@wifi-device[0].disabled=0
uci commit
wifi
/sbin/wifi makes the following ubus calls,
ubus call network reload
ubus call network.wireless down
ubus call network.wireless up
The first and third ubus calls both call drv_mac80211_setup,
while the second ubus call triggers wireless_device_setup_cancel.
So the call sequence becomes,
drv_mac80211_setup
wireless_device_setup_cancel
drv_mac80211_setup
In contrast, when LuCI is used to turn on wifi only a single call
is made to drv_mac80211_setup.
branches affected: trunk, 21.02
Signed-off-by: Bob Cantor <coxede6557@w3boats.com>
Use of WPA3 and things like FILS is getting much more common, and platforms
that can't affort the extra kilobytes for this code are fading away.
Let's not hold back modern authentication methods any longer
Signed-off-by: Felix Fietkau <nbd@nbd.name>
We need to skip sampling if the next sample time is after jiffies, not before.
This patch fixes an issue where in some cases only very little sampling (or none
at all) is performed, leading to really bad data rates
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The removed patches were integrated upstream.
The brcmf_driver_work workqueue was removed in brcmfmac with kernel
5.10.42, the asynchronous call was covered to a synchronous call. There
is no need to wait any more.
This part was removed manually from this patch:
brcm/860-brcmfmac-register-wiphy-s-during-module_init.patch
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The ath patch number is already large and adding other patch for ath11k
will add more confusion with the patch numbering.
Since the support of ath11k based device is imminent, prepare the mac80211
ath patch dir and split it in the dedicated ath5k, ath9k, ath10k and ath11k
(empty for now).
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Some drivers advertise it, but it's not supported at the moment
Reported-by: John Thomson <git@johnthomson.fastmail.com.au>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The colon does not directly follow the "VHT Capabilities" string
Reported-by: John Thomson <git@johnthomson.fastmail.com.au>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
ATH_REG_DYNAMIC_USER_REG_HINTS is currently not being set as mac80211
tries to set it as m which is not possible as its boolean only.
Since its used alongside user regulatory, move it to USER_REGD.
This is required for ath11k to accept regulatory changes, otherwise
it wont accept any changes and will simply force US.
Signed-off-by: Robert Marko <robimarko@gmail.com>
From the patch series description:
Several security issues in the 802.11 implementations were found by
Mathy Vanhoef (New York University Abu Dhabi), who has published all
the details at
https://papers.mathyvanhoef.com/usenix2021.pdf
Specifically, the following CVEs were assigned:
* CVE-2020-24586 - Fragmentation cache not cleared on reconnection
* CVE-2020-24587 - Reassembling fragments encrypted under different
keys
* CVE-2020-24588 - Accepting non-SPP A-MSDU frames, which leads to
payload being parsed as an L2 frame under an
A-MSDU bit toggling attack
* CVE-2020-26139 - Forwarding EAPOL from unauthenticated sender
* CVE-2020-26140 - Accepting plaintext data frames in protected
networks
* CVE-2020-26141 - Not verifying TKIP MIC of fragmented frames
* CVE-2020-26142 - Processing fragmented frames as full frames
* CVE-2020-26143 - Accepting fragmented plaintext frames in
protected networks
* CVE-2020-26144 - Always accepting unencrypted A-MSDU frames that
start with RFC1042 header with EAPOL ethertype
* CVE-2020-26145 - Accepting plaintext broadcast fragments as full
frames
* CVE-2020-26146 - Reassembling encrypted fragments with non-consecutive
packet numbers
* CVE-2020-26147 - Reassembling mixed encrypted/plaintext fragments
In general, the scope of these attacks is that they may allow an
attacker to
* inject L2 frames that they can more or less control (depending on the
vulnerability and attack method) into an otherwise protected network;
* exfiltrate (some) network data under certain conditions, this is
specific to the fragmentation issues.
A subset of these issues is known to apply to the Linux IEEE 802.11
implementation (mac80211). Where it is affected, the attached patches
fix the issues, even if not all of them reference the exact CVE IDs.
In addition, driver and/or firmware updates may be necessary, as well
as potentially more fixes to mac80211, depending on how drivers are
using it.
Specifically, for Intel devices, firmware needs to be updated to the
most recently released versions (which was done without any reference
to the security issues) to address some of the vulnerabilities.
To have a single set of patches, I'm also including patches for the
ath10k and ath11k drivers here.
We currently don't have information about how other drivers are, if
at all, affected.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Missing braces in a macro were leading to badly working rates sometimes
getting a success probabilty of 1.0
Signed-off-by: Felix Fietkau <nbd@nbd.name>
When transmitting to a receiver in dynamic SMPS mode, all transmissions that
use multiple spatial streams need to be sent using CTS-to-self or RTS/CTS to
give the receiver's extra chains some time to wake up.
This fixes the tx rate getting stuck at <= MCS7 for some clients, especially
Intel ones, which make aggressive use of SMPS.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
On hardware that supports this, this will improve performance by passing
802.3 frames from the hardware to the stack
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The removed patches were applied upstream.
This adapts ath10k-ct and mt76 to changed APIs.
nl80211.h in iw is updated to match the version from backports.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The removed patches were applied upstream.
Remove the 300-mac80211-optimize-skb-resizing.patch.
This patch was not applied upstream, but it conflicts with upstream
changes and needs bigger changes. It was applied with Felix to remove
this patch for now. It should be reworked and then send upstream later.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Multiple sources are hosted on OpenWrts source server only. The source
URLs to point to the server vary based on different epochs in OpenWrts
history.
Replace all by @OPENWRT which is an "empty" mirror, therefore using the
fallback servers sources.cdn.openwrt.org and sources.openwrt.org.
Signed-off-by: Paul Spooren <mail@aparcar.org>
If the driver uses .sta_add, station entries are only uploaded after the sta
is in assoc state. Fix early station rate table updates by deferring them
until the sta has been uploaded
Signed-off-by: Felix Fietkau <nbd@nbd.name>
