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>
* mac80211: allow VHT on 2.4GHz
Allow VHT rate on 2.4GHz in order to use 256-QAM
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
* ath10k: allow VHT on 2.4GHz
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
* hostapd: add vendor_vht option
hostapd has vendor_vht option to enable VHT (256-QAM) on 2.4GHz
Add this option to hostapd.sh so users can enable it via uci
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
* mac80211: ath.mk: typo fixes
Co-authored-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
* mac80211: remove patches stripping down crypto support
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>
* kernel: make cryptoapi support needed by mac80211 built-in
This reduces the flash space impact, since built-in code is much smaller
than a bunch of kernel modules on squashfs
Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: remove extra patch accidentally added during rebase
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Co-authored-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>
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>
Co-authored-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>
Co-authored-by: Felix Fietkau <nbd@nbd.name>
[mac80211]
5b29614 mac80211: another fix for the sta connection monitor
1ed6eb1 mac80211: backport sched_set_fifo_low
cba4120 mac80211: add support for specifying a per-device scan list
e0d482f rt2x00: mt7620: differentiate based on SoC's CHIP_VER
[package]
amd64-microcode/intel-microcode/linux-firmware: update version
[mac80211]
ca5ee6e mac80211: Fix potential endless loop
2c14710 mac80211: add more AQL fixes/improvements
91fb3ce mac80211: remove an obsolete patch that is no longer doing anything useful
acf1733 mac80211: add preliminary support for enabling 802.11ax in config
d717343 mac80211: update encap offload patches to the latest version
673062f mac80211: allow bigger A-MSDU sizes in VHT, even if HT is limited
caf7277 mac80211: do not allow bigger VHT MPDUs than the hardware supports
cd36c0d mac80211: select the first available channel for 5GHz interfaces
1c6d456 mac80211: fix regression in station connection monitor optimization
4bd7689 mac80211: update sta connection monitor regression fix
[target]
Sync: at91, ath25, ath79, lantiq, mediatek, mvebu.
kernel: bump to 4.14.193, 4.19.138, 5.4.59 (#5350)
431fb8c mac80211: add AQL improvements
6bdd4c9 mac80211: add missing backports for building with 4.14 kernels
0106820 mac80211: add missing return code checks in AQL improvements
e7f7101 mac80211: rework encapsulation offload support
[package]
base-files: add function for generating random MAC
dnsmasq: abort dhcp_check on interface state
boot: sync upstream source code
ath10k-ct-firmware/mt76/sch_cake: update to latest git HEAD
[script]
download: add China Mirror Station
[target]
Sync: arc770, ath79, bcm63xx, kirkwood, lantiq, layerscape,
mediatek, mvebu, octeon, oxnas, pistachio, uml
Sync most of the target patches.
Run-compiled-on: ipq40xx (4.19 & 5.4), ramips
* mac80211: bump to 5.8-rc2
changelog:
dfe0bc8 mac80211: allow ACS restriction with fixed channel
727685c mac80211: rt2x00: define RF5592 in init_eeprom routine
cfd2f3b mac80211: create channel list for fixed channel operation
d1100c7 mac80211: Update to version 5.7.5-1
ed2015c mac80211: Update to version 5.8-rc2-1
a956c14 mac80211: util: don't warn on missing sband iftype data
8b3e170 hostapd: fix incorrect service name
68bf5a9 mac80211: don't kill wireless daemon on teardown
25e0ae6 mac80211: make cfg80211 testmode support optional (and disabled by default)
b7727a8 mac80211: fix AQL issues
3d731fc mac80211: merge performance improvement patches
* mt76: update to 2020-07-22
Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mac80211: allow VHT on 2.4GHz
Allow VHT rate on 2.4GHz in order to use 256-QAM
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
* ath10k: allow VHT on 2.4GHz
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
* hostapd: add vendor_vht option
hostapd has vendor_vht option to enable VHT (256-QAM) on 2.4GHz
Add this option to hostapd.sh so users can enable it via uci
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
* ipq807x: Refresh kernel configuration
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* ipq807x: Add WCSS bus
This is needed to build ath11k.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* mac80211: Add ath11k
This adds the Qualcomm 802.11ax wireless chipset support.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Co-authored-by: Felix Fietkau <nbd@nbd.name>
Co-authored-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
Co-authored-by: Hauke Mehrtens <hauke@hauke-m.de>
