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>
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>
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>
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>
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>
Remove deferred sampling code which does not work well with rate tables +
probing.
Fix tx status handling if the first invalid rate idx is not set to -1
Signed-off-by: Felix Fietkau <nbd@nbd.name>
rt2800 olny gives you survey for current channel.
Survey-based ACS algorithms are failing to perform their job when working
with rt2800.
Make rt2800 save survey for every channel visited and be able to give away
that information.
There is a bug registred https://dev.archive.openwrt.org/ticket/19081 and
this patch solves the issue.
Signed-off-by: Markov Mikhail <markov.mikhail@itmh.ru>
After the status rework, ieee80211_tx_status_ext is leaking un-acknowledged
packets for stations in powersave mode.
To fix this, move the code handling those packets from __ieee80211_tx_status
into ieee80211_tx_status_ext
Reported-by: Tobias Waldvogel <tobias.waldvogel@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The vendor driver does things differently based on what it finds in the
SoC's CHIP_VER register, which should tell whether this is MT7620N or
MT7620A (PKG) and probably also the revision (VER) and most likely
also something about the silicon implementer (ECO).
Introduce codepaths just like the ones in the vendor driver to handle
the different chips properly.
Some of those paths are most likely dead code and left-overs from FPGA
versions or early prototypes of the chip. It'd thus be great if people
can post their kernel logs, at least the line telling the chip version
and eco, so we know what's actually out there in the wild -- all I
could find is
[ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6
and
[ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6
which would make things easier, as then we really just need to know
whether it's MT7620N or MT7620A and not care about FPGA or prototypes
with ver <= 1 and eco <= 2.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
When the nulldata frame was acked, the probe send count needs to be reset,
otherwise it will keep increasing until the connection is considered dead,
even though it fine.
Reported-by: Georgi Valkov <gvalkov@abv.bg>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Minor cleanup and code reorganization, along with a change to not disable
offload anymore when a tkip or sw crypto key is added
Signed-off-by: Felix Fietkau <nbd@nbd.name>
mac80211 reports a packet loss event to user space when 50 consecutive packets
were not acked. On a high throughput link with long aggregates and sudden
link changes, this can trigger way too easily.
Mitigate false positives by only triggering the event on a packet loss if
no ACK was received for at least a second
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Exchange the patch fixing the kernel ringbuffer WARNING flood for the
one accepted upstream.
Fixes commit a956c14d6a ("mac80211: util: don't warn on missing sband
iftype data")
Signed-off-by: David Bauer <mail@david-bauer.net>
The kernel currently floods the ringbuffer with warnings when adding a
mesh interface for a device not support HE 6GHz modes.
Return without warning in this case, as mesh_add_he_6ghz_cap_ie calls
ieee80211_ie_build_he_6ghz_cap regardless of the supported interface
modes.
Signed-off-by: David Bauer <mail@david-bauer.net>
The following patches:
* 972-ath10k_fix-crash-due-to-wrong-handling-of-peer_bw_rxnss_override-parameter.patch
* 973-ath10k_fix-band_center_freq-handling-for-VHT160-in-recent-firmwares.patch
are replaced by this commit in the upstream kernel:
* 3db24065c2c8 ("ath10k: enable VHT160 and VHT80+80 modes")
The following patches were applied upstream:
* 001-rt2800-enable-MFP-support-unconditionally.patch
* 090-wireless-Use-linux-stddef.h-instead-of-stddef.h.patch
The rtw88 driver is now split into multiple kernel modules, just put it
all into one OpenWrt kernel package.
rtl8812au-ct was patched to compile against the mac80211 from kernel
5.8, but not runtime tested.
Add a patch which fixes ath10k on IPQ40XX, this patch was send upstream
and fixes a crash when loading ath10k on this SoC.
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [ipq40xx/ map-ac2200]
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Make sure RF5592 is set for RT5592 chip which apparently sometimes
doesn't have RF defined (but always comes with RF5592).
This patch was originally submitted on linux-wireless by
Tom Psyborg <pozega.tomislav@gmail.com> but got rejected.
Turns out the patch is actually needed.
Reported-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
ath9k will already fallback on software-crypto for chipsets not
supporting IEEE802.11w (MFP). So advertising MFP is not dependent
on disabling HW crypto for all traffic entirely.
Tested on Sonicwall SonicPoint Ni (AR9132)
Signed-off-by: David Bauer <mail@david-bauer.net>
From: Rui Salvaterra <rsalvaterra@gmail.com>
Date: Mon, 25 May 2020 14:49:07 +0100
Subject: [PATCH] rt2800: enable MFP support unconditionally
This gives us WPA3 support out of the box without having to manually disable
hardware crypto. The driver will fall back to software crypto if the connection
requires management frame protection.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This fixes the following compile error seen on the mpc85xx target:
CC [M] /linux-mpc85xx_p2020/backports-5.7-rc3-1/drivers/net/wireless/intersil/orinoco/main.o
In file included from /builder/shared-workdir/build/staging_dir/toolchain-powerpc_8540_gcc-8.4.0_musl/include/stddef.h:17,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/include/uapi/linux/wireless.h:77,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/include/linux/wireless.h:13,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/drivers/net/wireless/intersil/orinoco/main.c:89:
/builder/shared-workdir/build/staging_dir/toolchain-powerpc_8540_gcc-8.4.0_musl/include/bits/alltypes.h:106:15: error: conflicting types for 'ptrdiff_t'
typedef _Addr ptrdiff_t;
^~~~~~~~~
In file included from /linux-mpc85xx_p2020/backports-5.7-rc3-1/backport-include/linux/types.h:4,
from ./include/linux/list.h:5,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/backport-include/linux/list.h:3,
from ./include/linux/module.h:9,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/backport-include/linux/module.h:3,
from /linux-mpc85xx_p2020/backports-5.7-rc3-1/drivers/net/wireless/intersil/orinoco/main.c:79:
./include/linux/types.h:65:28: note: previous declaration of 'ptrdiff_t' was here
typedef __kernel_ptrdiff_t ptrdiff_t;
^~~~~~~~~
scripts/Makefile.build:265: recipe for target '/linux-mpc85xx_p2020/backports-5.7-rc3-1/drivers/net/wireless/intersil/orinoco/main.o' failed
Fixes: 289c632425 ("mac80211: Update to version 5.7-rc3-1")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This updates the mac80211 backport.
The removed patches are already integrated in the upstream version.
The 131-Revert-mac80211-aes-cmac-switch-to-shash-CMAC-driver.patch patch
was manually adapted to the changes in kernel 5.7.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This updates the mac80211 backport.
The removed patches are already integrated in the upstream version.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This updates the mac80211 backport.
The removed patches are already integrated in the upstream version.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This updates the mac80211 backport to the latest minor version.
The removed patch was a backport from the upstream kernel which is now
integrated.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Before, only frames with a maximum size of 1528 bytes could be
transmitted between two 802.11s nodes.
For batman-adv for instance, which adds its own header to each frame,
we typically need an MTU of at least 1532 bytes to be able to transmit
without fragmentation.
This patch now increases the maxmimum frame size from 1528 to 1656
bytes.
Tested with two ath10k devices in 802.11s mode, as well as with
batman-adv on top of 802.11s with forwarding disabled.
Fix originally found and developed by Ben Greear.
Link: https://github.com/greearb/ath10k-ct/issues/89
Link: 9e5ab25027
Cc: Ben Greear <greearb@candelatech.com>
Signed-off-by: Linus Lüssing <ll@simonwunderlich.de>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
If we know that we have an encrypted link (based on having had
a key configured for TX in the past) then drop all data frames
in the key selection handler if there's no key anymore.
This fixes an issue with mac80211 internal TXQs - there we can
buffer frames for an encrypted link, but then if the key is no
longer there when they're dequeued, the frames are sent without
encryption. This happens if a station is disconnected while the
frames are still on the TXQ.
Detecting that a link should be encrypted based on a first key
having been configured for TX is fine as there are no use cases
for a connection going from with encryption to no encryption.
With extended key IDs, however, there is a case of having a key
configured for only decryption, so we can't just trigger this
behaviour on a key being configured.
Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: David Bauer <mail@david-bauer.net>
The calibration patches for MT7620 unnecessarily export symbols and
populate never accessed function pointers. Remove all that and make
functions static as the only place where each of those functions is
called is within rt2800lib.c.
Also make code more readable by fixing indentation, removing
unnecessary parantheses and simplifying some instructions using
shorthands here and there.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Do not export static functions, they are anyway not referenced by any
code in a different module.
This fixes the following compile warning:
WARNING: "rt2800_rf_aux_tx0_loopback" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
WARNING: "rt2800_write_dc" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
WARNING: "rt2800_rf_configstore" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
WARNING: "rt2800_do_sqrt_accumulation" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
WARNING: "rt2800_rf_configrecover" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
WARNING: "rt2800_loft_search" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
WARNING: "rt2800_iq_search" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
WARNING: "rt2800_setbbptonegenerator" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
WARNING: "rt2800_rf_aux_tx1_loopback" [/drivers/net/wireless/ralink/rt2x00/rt2800lib] is a static EXPORT_SYMBOL_GPL
Acked-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
On platforms that do not have CONFIG_MTD enabled, loading the
rt2x00lib kernel module fails because it depends on symbols from
the mtd module ("Unknown symbol get_mtd_device_nm").
This commit disables the code that can read the eeprom from mtd if
mtd is not enabled.
Signed-off-by: Sven Over <sp@cedenti.st>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
ath10k-ct supports the combination to select IBSS (ADHOC) mode and
different beacon intervals together. mac80211 does not like this
combination, but Ben says this is ok, so remove this check.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
