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>
Enable support for the Ubiquiti UniFi Outdoor+ RF filter via
device-tree. The old way of using platform data is not required anymore,
as it was only used on the now removed ar71xx target.
Signed-off-by: David Bauer <mail@david-bauer.net>
This patch adds wil6210 driver for Wilocity/QCA based 802.11ad
PCI cards.
Driver uses cfg80211 and nl80211 but not mac80211.
Integration for UCI and LuCI will come in other patches.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Legacy minstrel is essentially unmaintained and was showing poor performance
Replace it with minstrel_ht and improve rate selection and sampling behavior
Signed-off-by: Felix Fietkau <nbd@nbd.name>
As of hostapd upstream commit 7d2ed8ba "Remove CONFIG_IEEE80211W build parameter"
https://w1.fi/cgit/hostap/commit?id=7d2ed8bae86a31dd2df45c24b3f7281d55315482
802.11w feature is always enabled in the build time.
It doesn't make sense to opt-in 802.11w per driver as hostapd will always
be compiled with this feature enabled.
As suggested by Hauke Mehrtens, for now keep 11w enabled in build_features.h
for compatibility reasons. This option will be dropped when LuCI is adjusted.
Signed-off-by: Dobroslaw Kijowski <dobo90@gmail.com>
