[LEDE-DEV] [PATCH] ath10k-firmware: Update QCA988X firmware to the latest version
This patch updates the QCA988X firmware to the latest revision firmware-5.bin_10.2.4-1.0-00037 found in the ath10k-firmware and linux-firmware repositories. Tested on TP-Link Archer C7 v2 (ar71xx). Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de> --- package/firmware/ath10k-firmware/Makefile | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile index 6b81e1a..cc9ab36 100644 --- a/package/firmware/ath10k-firmware/Makefile +++ b/package/firmware/ath10k-firmware/Makefile @@ -8,9 +8,9 @@ include $(TOPDIR)/rules.mk PKG_NAME:=ath10k-firmware -PKG_SOURCE_DATE:=2018-04-19 -PKG_SOURCE_VERSION:=71e50312b54cc972657a7b08c470088447cb9676 -PKG_MIRROR_HASH:=726e7bce9917532e3b39ced6a17ca2d4c39fdf4c9bec4a3f8f2ea3e5defa6a54 +PKG_SOURCE_DATE:=2018-05-12 +PKG_SOURCE_VERSION:=952afa4949cb34193040cd4e7441e1aee50ac731 +PKG_MIRROR_HASH:=0040f94d11d0039505328a90b2ff48968db873e9e7967307631bf40ef5679275 PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git @@ -433,7 +433,7 @@ define Package/ath10k-firmware-qca988x/install $(PKG_BUILD_DIR)/QCA988X/hw2.0/board.bin \ $(1)/lib/firmware/ath10k/QCA988X/hw2.0/ $(INSTALL_DATA) \ - $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00033 \ + $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00037 \ $(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin endef -- 2.1.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] ath10k-firmware: Update QCA988X firmware to the latest version
Hi, the following patch merely updates the ath10k/QCA988X firmware to the latest version found in the ath10k firmware repository which is the same version that is currently in the linux-firmware repository. I have tested this firmware release for almost 3 months now on a TP-Link Archer C7 v2 without any issues. Please apply this to the openwrt-18.06 branch as well. Thanks, Timo Timo Sigurdsson (1): ath10k-firmware: Update QCA988X firmware to the latest version package/firmware/ath10k-firmware/Makefile | 8 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.1.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH resend 3/3] hostapd: bump PKG_RELEASE
Hi Stijn, Stijn Tintel schrieb am 07.12.2017 12:05: > On 07-12-17 12:04, Timo Sigurdsson wrote: >> Hi, >> >> Stijn Tintel schrieb am 07.12.2017 01:35: >> >>> On 14-11-17 21:41, Timo Sigurdsson wrote: >>>> Increase PKG_RELEASE after latest changes to hostapd, so downstream >>>> users can fetch updates via opkg. >>>> >>> You should have bumped PKG_RELEASE in the previous commit. I've done >>> that in my staging tree. >>> >> thanks for the fixup. I'll send patches later tonight backporting these two >> commits >> to the 17.04 branch. >> > If they can be cherry-picked that is the preferred method, then there is > no need to send patches. I can look into it tonight. > even better so! Thanks. Regards, Timo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH resend 3/3] hostapd: bump PKG_RELEASE
Hi, Stijn Tintel schrieb am 07.12.2017 01:35: > On 14-11-17 21:41, Timo Sigurdsson wrote: >> Increase PKG_RELEASE after latest changes to hostapd, so downstream >> users can fetch updates via opkg. >> > You should have bumped PKG_RELEASE in the previous commit. I've done > that in my staging tree. > thanks for the fixup. I'll send patches later tonight backporting these two commits to the 17.04 branch. Regards, Timo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH resend 1/3] hostapd: Expose the tdls_prohibit option to UCI
wpa_disable_eapol_key_retries can't prevent attacks against the
Tunneled Direct-Link Setup (TDLS) handshake. Jouni Malinen suggested
that the existing hostapd option tdls_prohibit can be used to further
complicate this possibility at the AP side. tdls_prohibit=1 makes
hostapd advertise that use of TDLS is not allowed in the BSS.
Note: If an attacker manages to lure both TDLS peers into a fake
AP, hiding the tdls_prohibit advertisement from them, it might be
possible to bypass this protection.
Make this option configurable via UCI, but disabled by default.
Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
---
package/network/services/hostapd/files/hostapd.sh | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/package/network/services/hostapd/files/hostapd.sh
b/package/network/services/hostapd/files/hostapd.sh
index 16925d5..dc7640a 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -151,6 +151,8 @@ hostapd_common_add_bss_config() {
wpa_group_rekey wpa_pair_rekey wpa_master_rekey
config_add_boolean wpa_disable_eapol_key_retries
+ config_add_boolean tdls_prohibit
+
config_add_boolean rsn_preauth auth_cache
config_add_int ieee80211w
config_add_int eapol_version
@@ -215,7 +217,7 @@ hostapd_set_bss_options() {
json_get_vars \
wep_rekey wpa_group_rekey wpa_pair_rekey wpa_master_rekey \
- wpa_disable_eapol_key_retries \
+ wpa_disable_eapol_key_retries tdls_prohibit \
maxassoc max_inactivity disassoc_low_ack isolate auth_cache \
wps_pushbutton wps_label ext_registrar wps_pbc_in_m1
wps_ap_setup_locked \
wps_independent wps_device_type wps_device_name
wps_manufacturer wps_pin \
@@ -232,6 +234,7 @@ hostapd_set_bss_options() {
set_default wmm 1
set_default uapsd 1
set_default wpa_disable_eapol_key_retries 0
+ set_default tdls_prohibit 0
set_default eapol_version 0
set_default acct_port 1813
@@ -252,6 +255,8 @@ hostapd_set_bss_options() {
append bss_conf "ignore_broadcast_ssid=$hidden" "$N"
append bss_conf "uapsd_advertisement_enabled=$uapsd" "$N"
+ [ "$tdls_prohibit" -gt 0 ] && append bss_conf
"tdls_prohibit=$tdls_prohibit" "$N"
+
[ "$wpa" -gt 0 ] && {
[ -n "$wpa_group_rekey" ] && append bss_conf
"wpa_group_rekey=$wpa_group_rekey" "$N"
[ -n "$wpa_pair_rekey" ] && append bss_conf
"wpa_ptk_rekey=$wpa_pair_rekey""$N"
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH resend 2/3] hostapd: Backport Ignore WNM-Sleep Mode Request in wnm_sleep_mode=0 case
wpa_disable_eapol_key_retries can't prevent attacks against the Wireless
Network Management (WNM) Sleep Mode handshake. Currently, hostapd
processes WNM Sleep Mode requests from clients regardless of the setting
wnm_sleep_mode. Backport Jouni Malinen's upstream patch 114f2830 in
order to ignore such requests by clients when wnm_sleep_mode is disabled
(which is the default).
Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
---
...WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch | 35 ++
1 file changed, 35 insertions(+)
create mode 100644
package/network/services/hostapd/patches/013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch
diff --git
a/package/network/services/hostapd/patches/013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch
b/package/network/services/hostapd/patches/013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch
new file mode 100644
index 000..13426e4
--- /dev/null
+++
b/package/network/services/hostapd/patches/013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch
@@ -0,0 +1,35 @@
+From 114f2830d2c2aee6db23d48240e93415a256a37c Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <jo...@qca.qualcomm.com>
+Date: Fri, 20 Oct 2017 17:39:42 +0300
+Subject: [PATCH] WNM: Ignore WNM-Sleep Mode Request in wnm_sleep_mode=0 case
+
+The hostapd wnm_sleep_mode parameter was previously used to control
+advertisement of WNM-Sleep Mode support, but it was not used when
+processing a request to use WNM-Sleep Mode. Add an explicit check during
+request processing as well so that any misbehaving station is ignored.
+
+Signed-off-by: Jouni Malinen <jo...@qca.qualcomm.com>
+---
+ src/ap/wnm_ap.c | 7 +++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/src/ap/wnm_ap.c b/src/ap/wnm_ap.c
+index 7c4fde0..973e4d3 100644
+--- a/src/ap/wnm_ap.c
b/src/ap/wnm_ap.c
+@@ -200,6 +200,13 @@ static void ieee802_11_rx_wnmsleep_req(struct
hostapd_data *hapd,
+ u8 *tfsreq_ie_end = NULL;
+ u16 tfsreq_ie_len = 0;
+
++ if (!hapd->conf->wnm_sleep_mode) {
++ wpa_printf(MSG_DEBUG, "Ignore WNM-Sleep Mode Request from "
++ MACSTR " since WNM-Sleep Mode is disabled",
++ MAC2STR(addr));
++ return;
++ }
++
+ dialog_token = *pos++;
+ while (pos + 1 < frm + len) {
+ u8 ie_len = pos[1];
+--
+2.1.4
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH resend 0/3] hostapd: Address some limitations of wpa_disable_eapol_key_retries
Hi, I'm resending this series of patches as they seem to have gone unnoticed so far on the mailing list. In a discussion on the hostap mailing list about the limitations of the new hostapd parameter wpa_disable_eapol_key_retries as an AP side workaround for the Key Reinstallation Attacks (KRACK), two corner cases were mentioned along with suggestions how to address them [1][2]. The changes are fairly simple and may help users to further narrow the attack surface from the AP side (in case there are clients that are still vulnerable). The first allows to prohibit the use of TDLS on the network via an already existing hostapd parameter that just needs to be made configurable via UCI. The second is an upstream patch to ensure WNM Sleep Mode requests are ignored unless WNM Sleep Mode is enabled (which it isn't by default). I'm planning to post patches backporting these changes to the v17.01 branch as well. Regards, Timo Timo Sigurdsson (3): hostapd: Expose the tdls_prohibit option to UCI hostapd: Backport Ignore WNM-Sleep Mode Request in wnm_sleep_mode=0 case hostapd: bump PKG_RELEASE package/network/services/hostapd/Makefile | 2 +- package/network/services/hostapd/files/hostapd.sh | 7 - ...WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch | 35 ++ 3 files changed, 42 insertions(+), 2 deletions(-) create mode 100644 package/network/services/hostapd/patches/013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch -- 2.1.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH resend 3/3] hostapd: bump PKG_RELEASE
Increase PKG_RELEASE after latest changes to hostapd, so downstream users can fetch updates via opkg. Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de> --- package/network/services/hostapd/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/network/services/hostapd/Makefile b/package/network/services/hostapd/Makefile index 5a353e6..f1d057d 100644 --- a/package/network/services/hostapd/Makefile +++ b/package/network/services/hostapd/Makefile @@ -7,7 +7,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=hostapd -PKG_RELEASE:=3 +PKG_RELEASE:=4 PKG_SOURCE_URL:=http://w1.fi/hostap.git PKG_SOURCE_PROTO:=git -- 2.1.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/3] hostapd: Backport Ignore WNM-Sleep Mode Request in wnm_sleep_mode=0 case
wpa_disable_eapol_key_retries can't prevent attacks against the Wireless
Network Management (WNM) Sleep Mode handshake. Currently, hostapd
processes WNM Sleep Mode requests from clients regardless of the setting
wnm_sleep_mode. Backport Jouni Malinen's upstream patch 114f2830 in
order to ignore such requests by clients when wnm_sleep_mode is disabled
(which is the default).
Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
---
...WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch | 35 ++
1 file changed, 35 insertions(+)
create mode 100644
package/network/services/hostapd/patches/013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch
diff --git
a/package/network/services/hostapd/patches/013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch
b/package/network/services/hostapd/patches/013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch
new file mode 100644
index 000..13426e4
--- /dev/null
+++
b/package/network/services/hostapd/patches/013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch
@@ -0,0 +1,35 @@
+From 114f2830d2c2aee6db23d48240e93415a256a37c Mon Sep 17 00:00:00 2001
+From: Jouni Malinen <jo...@qca.qualcomm.com>
+Date: Fri, 20 Oct 2017 17:39:42 +0300
+Subject: [PATCH] WNM: Ignore WNM-Sleep Mode Request in wnm_sleep_mode=0 case
+
+The hostapd wnm_sleep_mode parameter was previously used to control
+advertisement of WNM-Sleep Mode support, but it was not used when
+processing a request to use WNM-Sleep Mode. Add an explicit check during
+request processing as well so that any misbehaving station is ignored.
+
+Signed-off-by: Jouni Malinen <jo...@qca.qualcomm.com>
+---
+ src/ap/wnm_ap.c | 7 +++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/src/ap/wnm_ap.c b/src/ap/wnm_ap.c
+index 7c4fde0..973e4d3 100644
+--- a/src/ap/wnm_ap.c
b/src/ap/wnm_ap.c
+@@ -200,6 +200,13 @@ static void ieee802_11_rx_wnmsleep_req(struct
hostapd_data *hapd,
+ u8 *tfsreq_ie_end = NULL;
+ u16 tfsreq_ie_len = 0;
+
++ if (!hapd->conf->wnm_sleep_mode) {
++ wpa_printf(MSG_DEBUG, "Ignore WNM-Sleep Mode Request from "
++ MACSTR " since WNM-Sleep Mode is disabled",
++ MAC2STR(addr));
++ return;
++ }
++
+ dialog_token = *pos++;
+ while (pos + 1 < frm + len) {
+ u8 ie_len = pos[1];
+--
+2.1.4
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/3] hostapd: Expose the tdls_prohibit option to UCI
wpa_disable_eapol_key_retries can't prevent attacks against the
Tunneled Direct-Link Setup (TDLS) handshake. Jouni Malinen suggested
that the existing hostapd option tdls_prohibit can be used to further
complicate this possibility at the AP side. tdls_prohibit=1 makes
hostapd advertise that use of TDLS is not allowed in the BSS.
Note: If an attacker manages to lure both TDLS peers into a fake
AP, hiding the tdls_prohibit advertisement from them, it might be
possible to bypass this protection.
Make this option configurable via UCI, but disabled by default.
Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
---
package/network/services/hostapd/files/hostapd.sh | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/package/network/services/hostapd/files/hostapd.sh
b/package/network/services/hostapd/files/hostapd.sh
index 16925d5..dc7640a 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -151,6 +151,8 @@ hostapd_common_add_bss_config() {
wpa_group_rekey wpa_pair_rekey wpa_master_rekey
config_add_boolean wpa_disable_eapol_key_retries
+ config_add_boolean tdls_prohibit
+
config_add_boolean rsn_preauth auth_cache
config_add_int ieee80211w
config_add_int eapol_version
@@ -215,7 +217,7 @@ hostapd_set_bss_options() {
json_get_vars \
wep_rekey wpa_group_rekey wpa_pair_rekey wpa_master_rekey \
- wpa_disable_eapol_key_retries \
+ wpa_disable_eapol_key_retries tdls_prohibit \
maxassoc max_inactivity disassoc_low_ack isolate auth_cache \
wps_pushbutton wps_label ext_registrar wps_pbc_in_m1
wps_ap_setup_locked \
wps_independent wps_device_type wps_device_name
wps_manufacturer wps_pin \
@@ -232,6 +234,7 @@ hostapd_set_bss_options() {
set_default wmm 1
set_default uapsd 1
set_default wpa_disable_eapol_key_retries 0
+ set_default tdls_prohibit 0
set_default eapol_version 0
set_default acct_port 1813
@@ -252,6 +255,8 @@ hostapd_set_bss_options() {
append bss_conf "ignore_broadcast_ssid=$hidden" "$N"
append bss_conf "uapsd_advertisement_enabled=$uapsd" "$N"
+ [ "$tdls_prohibit" -gt 0 ] && append bss_conf
"tdls_prohibit=$tdls_prohibit" "$N"
+
[ "$wpa" -gt 0 ] && {
[ -n "$wpa_group_rekey" ] && append bss_conf
"wpa_group_rekey=$wpa_group_rekey" "$N"
[ -n "$wpa_pair_rekey" ] && append bss_conf
"wpa_ptk_rekey=$wpa_pair_rekey""$N"
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 0/3] hostapd: Address some limitations of wpa_disable_eapol_key_retries
Hi, in a discussion on the hostap mailing list about the limitations of the new hostapd parameter wpa_disable_eapol_key_retries as an AP side workaround for the Key Reinstallation Attacks (KRACK), two corner cases were mentioned along with suggestions how to address them [1][2]. The changes are fairly simple and may help users to further narrow the attack surface from the AP side (in case there are clients that are still vulnerable). The first allows to prohibit the use of TDLS on the network via an already existing hostapd parameter that just needs to be made configurable via UCI. The second is an upstream patch to ensure WNM Sleep Mode requests are ignored unless WNM Sleep Mode is enabled (which it isn't by default). I'm planning to post patches backporting these changes to the v17.01 branch as well. Regards, Timo [1] http://lists.infradead.org/pipermail/hostap/2017-October/038005.html [2] http://lists.infradead.org/pipermail/hostap/2017-October/038007.html Timo Sigurdsson (3): hostapd: Expose the tdls_prohibit option to UCI hostapd: Backport Ignore WNM-Sleep Mode Request in wnm_sleep_mode=0 case hostapd: bump PKG_RELEASE package/network/services/hostapd/Makefile | 2 +- package/network/services/hostapd/files/hostapd.sh | 7 - ...WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch | 35 ++ 3 files changed, 42 insertions(+), 2 deletions(-) create mode 100644 package/network/services/hostapd/patches/013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch -- 2.1.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 3/3] hostapd: bump PKG_RELEASE
Increase PKG_RELEASE after latest changes to hostapd, so downstream users can fetch updates via opkg. Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de> --- package/network/services/hostapd/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/network/services/hostapd/Makefile b/package/network/services/hostapd/Makefile index 5a353e6..f1d057d 100644 --- a/package/network/services/hostapd/Makefile +++ b/package/network/services/hostapd/Makefile @@ -7,7 +7,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=hostapd -PKG_RELEASE:=3 +PKG_RELEASE:=4 PKG_SOURCE_URL:=http://w1.fi/hostap.git PKG_SOURCE_PROTO:=git -- 2.1.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ath10k-firmware: Update QCA988X firmware to latest version
Please forget about my email below. I've seen this crash again even with the older firmware, so I guess it's unrelated to the firmware verison. I'm currently testing if it might have to do with an option I enabled a few months back: management frame protection. So, I disabled that for now and will see if that changes anything. Thanks, Timo Timo Sigurdsson schrieb am 19.04.2017 10:22: > Hi, > > I'm recommending to revert this commit at least in the 17.01 stable > branch, since there have been reports on the forum about ath10k driver > crashes [1][2]. While I have not been able to reproduce the exact > described behaviour of the driver crashing at an early stage or in > short time, I did in fact experience a crash of the driver after about > 3 weeks uptime. > > I then went on to test the latest build > firmware-5.bin_10.2.4-1.0-00029 from kvalo's firmware repository and > after 2 weeks it crashed again. I suspect my issue is different from > the ones reported (I saved a crash log but can't find it right now, > unfortunately). Nevertheless, I think it's safer to revert this commit > at least on the 17.01 branch. > > Regards, > > Timo > > [1] > https://forum.lede-project.org/t/17-07-1-qca988x-ath10k-5ghz-firmware-crashed-zyxel-nbg6716/1911 > [2] https://forum.lede-project.org/t/5ghz-replacement-for-ath10k-card/3131 > > > Timo Sigurdsson schrieb am 11.01.2017 22:49: > >> This patch updates the QCA988X firmware to the latest revision >> firmware-5.bin_10.2.4-1.0-00016 >> found in the official ath10k-firmware repository. >> >> Tested on TP-Link Archer C7 v2. >> >> Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de> >> --- >> package/firmware/ath10k-firmware/Makefile | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/package/firmware/ath10k-firmware/Makefile >> b/package/firmware/ath10k-firmware/Makefile >> index 5091663..e441700 100644 >> --- a/package/firmware/ath10k-firmware/Makefile >> +++ b/package/firmware/ath10k-firmware/Makefile >> @@ -8,9 +8,9 @@ >> include $(TOPDIR)/rules.mk >> >> PKG_NAME:=ath10k-firmware >> -PKG_SOURCE_DATE:=2016-12-15 >> -PKG_SOURCE_VERSION:=fead2ed867af4e107265059b9f578179d7409867 >> -PKG_MIRROR_HASH:=87fb1998a728b3182d208b978185232decf49d1c72d1ec37c529fa9139354dcb >> +PKG_SOURCE_DATE:=2017-01-11 >> +PKG_SOURCE_VERSION:=ab432c60437931a165f0aff1a6e3371f358b75dd >> +PKG_MIRROR_HASH:=e3188ecd4d7470d3cdde89fefa6258f9ec4f404b23558d1474e5014679b28101 >> PKG_RELEASE:=1 >> >> PKG_SOURCE_PROTO:=git >> @@ -220,7 +220,7 @@ define Package/ath10k-firmware-qca988x/install >> $(PKG_BUILD_DIR)/QCA988X/hw2.0/board.bin \ >> $(1)/lib/firmware/ath10k/QCA988X/hw2.0/ >> $(INSTALL_DATA) \ >> - >> $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4.70/firmware-5.bin_10.2.4.70.59-2 \ >> + >> $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00016 \ >> $(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin >> endef >> >> -- >> 2.1.4 >> > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ath10k-firmware: Update QCA988X firmware to latest version
Hi, I'm recommending to revert this commit at least in the 17.01 stable branch, since there have been reports on the forum about ath10k driver crashes [1][2]. While I have not been able to reproduce the exact described behaviour of the driver crashing at an early stage or in short time, I did in fact experience a crash of the driver after about 3 weeks uptime. I then went on to test the latest build firmware-5.bin_10.2.4-1.0-00029 from kvalo's firmware repository and after 2 weeks it crashed again. I suspect my issue is different from the ones reported (I saved a crash log but can't find it right now, unfortunately). Nevertheless, I think it's safer to revert this commit at least on the 17.01 branch. Regards, Timo [1] https://forum.lede-project.org/t/17-07-1-qca988x-ath10k-5ghz-firmware-crashed-zyxel-nbg6716/1911 [2] https://forum.lede-project.org/t/5ghz-replacement-for-ath10k-card/3131 Timo Sigurdsson schrieb am 11.01.2017 22:49: > This patch updates the QCA988X firmware to the latest revision > firmware-5.bin_10.2.4-1.0-00016 > found in the official ath10k-firmware repository. > > Tested on TP-Link Archer C7 v2. > > Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de> > --- > package/firmware/ath10k-firmware/Makefile | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/package/firmware/ath10k-firmware/Makefile > b/package/firmware/ath10k-firmware/Makefile > index 5091663..e441700 100644 > --- a/package/firmware/ath10k-firmware/Makefile > +++ b/package/firmware/ath10k-firmware/Makefile > @@ -8,9 +8,9 @@ > include $(TOPDIR)/rules.mk > > PKG_NAME:=ath10k-firmware > -PKG_SOURCE_DATE:=2016-12-15 > -PKG_SOURCE_VERSION:=fead2ed867af4e107265059b9f578179d7409867 > -PKG_MIRROR_HASH:=87fb1998a728b3182d208b978185232decf49d1c72d1ec37c529fa9139354dcb > +PKG_SOURCE_DATE:=2017-01-11 > +PKG_SOURCE_VERSION:=ab432c60437931a165f0aff1a6e3371f358b75dd > +PKG_MIRROR_HASH:=e3188ecd4d7470d3cdde89fefa6258f9ec4f404b23558d1474e5014679b28101 > PKG_RELEASE:=1 > > PKG_SOURCE_PROTO:=git > @@ -220,7 +220,7 @@ define Package/ath10k-firmware-qca988x/install > $(PKG_BUILD_DIR)/QCA988X/hw2.0/board.bin \ > $(1)/lib/firmware/ath10k/QCA988X/hw2.0/ > $(INSTALL_DATA) \ > - > $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4.70/firmware-5.bin_10.2.4.70.59-2 \ > + > $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00016 \ > $(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin > endef > > -- > 2.1.4 > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] ath10k-firmware: Update QCA988X firmware to latest version
This patch updates the QCA988X firmware to the latest revision firmware-5.bin_10.2.4-1.0-00016 found in the official ath10k-firmware repository. Tested on TP-Link Archer C7 v2. Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de> --- package/firmware/ath10k-firmware/Makefile | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile index 5091663..e441700 100644 --- a/package/firmware/ath10k-firmware/Makefile +++ b/package/firmware/ath10k-firmware/Makefile @@ -8,9 +8,9 @@ include $(TOPDIR)/rules.mk PKG_NAME:=ath10k-firmware -PKG_SOURCE_DATE:=2016-12-15 -PKG_SOURCE_VERSION:=fead2ed867af4e107265059b9f578179d7409867 -PKG_MIRROR_HASH:=87fb1998a728b3182d208b978185232decf49d1c72d1ec37c529fa9139354dcb +PKG_SOURCE_DATE:=2017-01-11 +PKG_SOURCE_VERSION:=ab432c60437931a165f0aff1a6e3371f358b75dd +PKG_MIRROR_HASH:=e3188ecd4d7470d3cdde89fefa6258f9ec4f404b23558d1474e5014679b28101 PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git @@ -220,7 +220,7 @@ define Package/ath10k-firmware-qca988x/install $(PKG_BUILD_DIR)/QCA988X/hw2.0/board.bin \ $(1)/lib/firmware/ath10k/QCA988X/hw2.0/ $(INSTALL_DATA) \ - $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4.70/firmware-5.bin_10.2.4.70.59-2 \ + $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00016 \ $(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin endef -- 2.1.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [BUG] Kernel crashes with ath10k radio and Nexus 5X clients
80211 compat ledt rig_usbport ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables ifb ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common mii [283547.876293] CPU: 0 PID: 1841 Comm: hostapd Tainted: GW 4.4.32 #0 [283547.883714] Stack : 803c74e4 0001 8042 87d65b80 8040ed83 803a8bac 0731 [283547.883714] 8048379c 8740e800 7782fe94 800a7238 803ae218 8041 [283547.883714] 0003 8740e800 803ac624 86e1db2c 800a51b4 [283547.883714] 8040de90 801f3200 [283547.883714] [283547.883714] ... [283547.920171] Call Trace: [283547.922762] [<80071b80>] show_stack+0x50/0x84 [283547.927274] [<80081900>] warn_slowpath_common+0xa0/0xd0 [283547.932676] [<800819b8>] warn_slowpath_null+0x18/0x24 [283547.937995] [<87587050>] sta_set_sinfo+0x8d8/0x9e0 [mac80211] [283547.944054] [<87587188>] __sta_info_destroy+0x30/0x48 [mac80211] [283547.950349] [<87587238>] sta_info_destroy_addr_bss+0x38/0x60 [mac80211] [283547.957314] [<874cc144>] cfg80211_check_station_change+0xed8/0x1390 [cfg80211] [283547.964779] [283547.966381] ---[ end trace 1e173b5175dabd86 ]--- [283550.962647] ath10k_pci :01:00.0: failed to delete peer a0:02:dc:00:00:00 for vdev 0: -11 [283550.971316] ath10k_pci :01:00.0: found sta peer a0:02:dc:00:00:00 (ptr 86df6400 id 196) entry on vdev 0 after it was supposedly removed [283553.982619] ath10k_pci :01:00.0: failed to install key for vdev 0 peer 64:bc:0c:00:00:00: -11 [283553.991720] wlan0: failed to remove key (0, 64:bc:0c:00:00:00) from hardware (-11) [283554.017647] ath10k_pci :01:00.0: cipher 0 is not supported [283554.023706] ath10k_pci :01:00.0: failed to remove peer wep key 0: -122 [283554.030778] ath10k_pci :01:00.0: failed to clear all peer wep keys for vdev 0: -122 [283554.039005] ath10k_pci :01:00.0: failed to disassociate station: 64:bc:0c:00:00:00 vdev 0: -122 [283557.042589] ath10k_pci :01:00.0: failed to delete peer 64:bc:0c:00:00:00 for vdev 0: -11 [283557.051248] ath10k_pci :01:00.0: found sta peer 64:bc:0c:00:00:00 (ptr 86e31800 id 43) entry on vdev 0 after it was supposedly removed [283560.062553] ath10k_pci :01:00.0: failed to set beacon mode for vdev 0: -11 [283563.062522] ath10k_pci :01:00.0: failed to set dtim period for vdev 0: -11 [283566.077407] ath10k_pci :01:00.0: failed to recalculate rts/cts prot for vdev 0: -11 [283569.082474] ath10k_pci :01:00.0: failed to set protection mode 0 on vdev 0: -11 [283572.082447] ath10k_pci :01:00.0: failed to set preamble for vdev 0: -11 [283826.570252] ath10k_pci :01:00.0: failed to install key for vdev 0 peer 30:b5:c2:00:00:00: -11 [283826.579348] wlan0: failed to remove key (1, ff:ff:ff:ff:ff:ff) from hardware (-11) [283829.580227] ath10k_pci :01:00.0: failed to install key for vdev 0 peer 30:b5:c2:00:00:00: -11 [283829.589379] wlan0: failed to set key (1, ff:ff:ff:ff:ff:ff) to hardware (-11) Mohammed Shafi Shajakhan schrieb am 21.11.2016 13:47: > Hi Timo, > > sorry had I missed the exact kernel crash call trace ? > I could see only the warnings, can you please post the call > trace of the kernel crash please ? > > regards, > shafi > > On Sun, Nov 20, 2016 at 02:35:27AM +0100, Timo Sigurdsson wrote: >> Hi Adrian, >> >> sure - here's the bug report on kernel.org: >> https://bugzilla.kernel.org/show_bug.cgi?id=188201 >> >> Regards, >> >> Timo >> >> >> Adrian Chadd schrieb am 18.11.2016 22:22: >> >> > hiya! >> > >> > Can you file a kernel.org bug mentioning this? >> > >> > thanks! >> > >> > >> > -a >> > >> > >> > On 18 November 2016 at 01:30, Timo Sigurdsson >> > <public_tim...@silentcreek.de> wrote: >> >> Hi again, >> >> >> >> in the meantime, I have some more information to add to the issue >> >> mentioned >> in >> >> my email quoted further down below. >> >> >> >> Ben Greear approached me off-list and suggested to try the Candela Tech >> ath10k >> >> driver and firmware and see if the issue occurs with that as well. So, for >> the >> >> last 3 weeks I've been testing the CT driver and firmware and I can >> >> happily >> >> report that the issue with the driver crashing after a while when a Nexus >> 5X >> >> device is connected is not occuring with the current BETA 18 >> >> firmw
Re: [LEDE-DEV] [BUG] Kernel crashes with ath10k radio and Nexus 5X clients
Hi Mohammed, sorry for the late reply, but I was on a business trip last week. The log I had attached is all I got from this crash. I have no experience with kernel debugging, but I assume some info might be missing because the kernel was not compiled with debug information. So, I will have to provoke another crash with a different firmware image that has more debugging options enabled. It might take a few days, until the error occurs again, but I'll try to gather more information and post it. Regards, Timo Mohammed Shafi Shajakhan schrieb am 21.11.2016 13:47: > Hi Timo, > > sorry had I missed the exact kernel crash call trace ? > I could see only the warnings, can you please post the call > trace of the kernel crash please ? > > regards, > shafi > > On Sun, Nov 20, 2016 at 02:35:27AM +0100, Timo Sigurdsson wrote: >> Hi Adrian, >> >> sure - here's the bug report on kernel.org: >> https://bugzilla.kernel.org/show_bug.cgi?id=188201 >> >> Regards, >> >> Timo >> >> >> Adrian Chadd schrieb am 18.11.2016 22:22: >> >> > hiya! >> > >> > Can you file a kernel.org bug mentioning this? >> > >> > thanks! >> > >> > >> > -a >> > >> > >> > On 18 November 2016 at 01:30, Timo Sigurdsson >> > <public_tim...@silentcreek.de> wrote: >> >> Hi again, >> >> >> >> in the meantime, I have some more information to add to the issue >> >> mentioned >> in >> >> my email quoted further down below. >> >> >> >> Ben Greear approached me off-list and suggested to try the Candela Tech >> ath10k >> >> driver and firmware and see if the issue occurs with that as well. So, for >> the >> >> last 3 weeks I've been testing the CT driver and firmware and I can >> >> happily >> >> report that the issue with the driver crashing after a while when a Nexus >> 5X >> >> device is connected is not occuring with the current BETA 18 >> >> firmware-2-ct-full-community.bin. So, this really seems like a regression >> in >> >> the official API level 5 ath10k firmware blobs. >> >> >> >> The CT firmware is not perfect either, since it seems to suffer from a >> >> different >> >> bug that has been resolved in the official firmwares, and that is that >> after a >> >> reboot of my TP-Link Archer C7 v2, the ath10k driver won't load. Only >> >> after >> a >> >> hard reset or "cold boot" it will come up. That's an issue I had with >> >> older >> >> official firmwares as well, but it has been resolved with the recent API >> level >> >> 5 firmwares. >> >> >> >> Nevertheless, for the time being, I will stick to the CT firmware because >> >> I >> >> can >> >> work around the reboot issue and having the 5GHz wifi working for my Nexus >> 5X >> >> clients is more important. >> >> >> >> Over the next weeks, I will test different combinations of ath10k(-ct) >> driver >> >> and firmware to see if there's a combination that resolves all issues. >> >> This >> >> morning I flashed a LEDE build with the official ath10k driver and the CT >> >> firmware binary. >> >> >> >> But of course, if someone has more suggestions on what I could try or what >> >> information I could collect to help resolve the issue related to the Nexus >> 5X >> >> clients in the official firmware binaries, I think that would be >> >> beneficial >> >> for a larger audience. >> >> >> >> Regards, >> >> >> >> Timo >> >> >> >> P.S.: Please include my email address in any reply, since I'm not >> subscribed >> >> to the mailing list. Thank you. >> >> >> >> >> >> Timo Sigurdsson schrieb am 29.10.2016 22:19: >> >> >> >>> Hi everybody, >> >>> >> >>> I have a TP-Link Archer C7 v2 running a fairly recent build of LEDE >> (r1952, >> >>> Linux 4.4.26, compat-wireless-2016-10-08). It all works well except for >> the >> >>> fact that when I connect a Nexus 5X device to the 5GHz radio, the kernel >> or >> >>> ath10k driver will crash after a while. 5Ghz wifi will be dead after that >> >>> until I reboot the system. >> >>> >> >>
Re: [LEDE-DEV] [BUG] Kernel crashes with ath10k radio and Nexus 5X clients
Hi again, in the meantime, I have some more information to add to the issue mentioned in my email quoted further down below. Ben Greear approached me off-list and suggested to try the Candela Tech ath10k driver and firmware and see if the issue occurs with that as well. So, for the last 3 weeks I've been testing the CT driver and firmware and I can happily report that the issue with the driver crashing after a while when a Nexus 5X device is connected is not occuring with the current BETA 18 firmware-2-ct-full-community.bin. So, this really seems like a regression in the official API level 5 ath10k firmware blobs. The CT firmware is not perfect either, since it seems to suffer from a different bug that has been resolved in the official firmwares, and that is that after a reboot of my TP-Link Archer C7 v2, the ath10k driver won't load. Only after a hard reset or "cold boot" it will come up. That's an issue I had with older official firmwares as well, but it has been resolved with the recent API level 5 firmwares. Nevertheless, for the time being, I will stick to the CT firmware because I can work around the reboot issue and having the 5GHz wifi working for my Nexus 5X clients is more important. Over the next weeks, I will test different combinations of ath10k(-ct) driver and firmware to see if there's a combination that resolves all issues. This morning I flashed a LEDE build with the official ath10k driver and the CT firmware binary. But of course, if someone has more suggestions on what I could try or what information I could collect to help resolve the issue related to the Nexus 5X clients in the official firmware binaries, I think that would be beneficial for a larger audience. Regards, Timo P.S.: Please include my email address in any reply, since I'm not subscribed to the mailing list. Thank you. Timo Sigurdsson schrieb am 29.10.2016 22:19: > Hi everybody, > > I have a TP-Link Archer C7 v2 running a fairly recent build of LEDE (r1952, > Linux 4.4.26, compat-wireless-2016-10-08). It all works well except for the > fact that when I connect a Nexus 5X device to the 5GHz radio, the kernel or > ath10k driver will crash after a while. 5Ghz wifi will be dead after that > until I reboot the system. > > This issue has been reported before [1] and it also has been declared as > solved with newer firmwares [2] (but reopened by other users). However, even > with the latest firmware 10.2.4.70.58 from Kalle Valo's Github repository the > issue is far from resolved. I have tried many different firmware revisions > over the time (more recently 10.2.4.70.56 and 10.2.4.70.54), and I can could > only find that the issue sometimes takes longer to trigger with some firmwares > (which might just be random), but it would always occur at some point with API > level 5 firmwares. With API level 2 firmwares (which I testesd when I was > still using OpenWrt 15.05) I never saw these crashes, but the Nexus 5X had > other connectivity issues with these older firmwares that made this > combination no fun to use either. But this shows that the firmware itself > makes the difference here. > > I actually have two Nexus 5X on my network (my wife's and my own). I can > trigger the crash with either one of them. And if both Nexus 5X are connected > to the 5Ghz radio, then the issue triggers much faster (can be as low as 15 > minutes). My workaround is to let the Nexus 5X devices only connect to the > 2.4GHz radio. This way, the device can runs for weeks without any issue or > crash, but of course I would prefer the actual bug being fixed rather than to > circumvent it. > > I'm appending a syslog from my access point with a crash happening while one > Nexus 5X was connected to the 5GHz radio starting from the time the system > booted. I randomized the MAC addresses. but left the first two characters > unique so different clients can be distinguished. > > If there is more info I could collect to help identify the cause of this > issue, please let me know (and possibly how to do that as well). > > Thank you and regards, > > Timo > > [1] http://lists.infradead.org/pipermail/ath10k/2015-November/006413.html > [2] https://dev.openwrt.org/ticket/20854 > > And here's the log: > Fri Oct 28 02:01:35 2016 kern.notice kernel: [0.00] Linux version > 4.4.26 (user@buildsystem) (gcc version 5.4.0 (LEDE GCC 5.4.0 r1952) ) #0 Fri > Oct 21 15:52:28 2016 > [...] > Fri Oct 28 02:01:35 2016 kern.info kernel: [9.468751] Loading modules > backported from Linux version wt-2016-10-03-1-g6fcb1a6 > Fri Oct 28 02:01:35 2016 kern.info kernel: [9.476481] Backport generated > by > backports.git backports-20160324-9-g0e38f5c > Fri Oct 28 02:01:35 2016 kern.warn kernel: [9.576570] PCI: Enabling device > :01:00.0 ( -> 0002) > Fri Oct 28 02:
Re: [LEDE-DEV] [BUG] Kernel crashes with ath10k radio and Nexus 5X clients
Hi, this is reply to Jo's message [1] which was only sent to the mailing list, but not to me directly. As I am not subscribed to the mailing list, please excplicitly include me in future replies. Thank you. Jo-Philipp Wich schrieb am 31.10.2016 01:37: > Hi Timo, > > did you try with kmod-ath10k or kmod-ath10k-ct ? > > Might be worth trying the -ct variant, to see if it has the same issue. > > ~ Jo So far, all my testing has been done with the "official" kmod-ath10k. But Ben Greear also approached me off-list and recommended me to test the ath10k-ct driver and firmware. I will give it a try this week and see how it works. Thanks and regards, Timo [1] http://lists.infradead.org/pipermail/lede-dev/2016-October/003751.html ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [BUG] Kernel crashes with ath10k radio and Nexus 5X clients
Hi everybody, I have a TP-Link Archer C7 v2 running a fairly recent build of LEDE (r1952, Linux 4.4.26, compat-wireless-2016-10-08). It all works well except for the fact that when I connect a Nexus 5X device to the 5GHz radio, the kernel or ath10k driver will crash after a while. 5Ghz wifi will be dead after that until I reboot the system. This issue has been reported before [1] and it also has been declared as solved with newer firmwares [2] (but reopened by other users). However, even with the latest firmware 10.2.4.70.58 from Kalle Valo's Github repository the issue is far from resolved. I have tried many different firmware revisions over the time (more recently 10.2.4.70.56 and 10.2.4.70.54), and I can could only find that the issue sometimes takes longer to trigger with some firmwares (which might just be random), but it would always occur at some point with API level 5 firmwares. With API level 2 firmwares (which I testesd when I was still using OpenWrt 15.05) I never saw these crashes, but the Nexus 5X had other connectivity issues with these older firmwares that made this combination no fun to use either. But this shows that the firmware itself makes the difference here. I actually have two Nexus 5X on my network (my wife's and my own). I can trigger the crash with either one of them. And if both Nexus 5X are connected to the 5Ghz radio, then the issue triggers much faster (can be as low as 15 minutes). My workaround is to let the Nexus 5X devices only connect to the 2.4GHz radio. This way, the device can runs for weeks without any issue or crash, but of course I would prefer the actual bug being fixed rather than to circumvent it. I'm appending a syslog from my access point with a crash happening while one Nexus 5X was connected to the 5GHz radio starting from the time the system booted. I randomized the MAC addresses. but left the first two characters unique so different clients can be distinguished. If there is more info I could collect to help identify the cause of this issue, please let me know (and possibly how to do that as well). Thank you and regards, Timo [1] http://lists.infradead.org/pipermail/ath10k/2015-November/006413.html [2] https://dev.openwrt.org/ticket/20854 And here's the log: Fri Oct 28 02:01:35 2016 kern.notice kernel: [0.00] Linux version 4.4.26 (user@buildsystem) (gcc version 5.4.0 (LEDE GCC 5.4.0 r1952) ) #0 Fri Oct 21 15:52:28 2016 [...] Fri Oct 28 02:01:35 2016 kern.info kernel: [9.468751] Loading modules backported from Linux version wt-2016-10-03-1-g6fcb1a6 Fri Oct 28 02:01:35 2016 kern.info kernel: [9.476481] Backport generated by backports.git backports-20160324-9-g0e38f5c Fri Oct 28 02:01:35 2016 kern.warn kernel: [9.576570] PCI: Enabling device :01:00.0 ( -> 0002) Fri Oct 28 02:01:35 2016 kern.info kernel: [9.582475] ath10k_pci :01:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0 Fri Oct 28 02:01:35 2016 kern.warn kernel: [ 10.087609] ath10k_pci :01:00.0: Direct firmware load for ath10k/pre-cal-pci-:01:00.0.bin failed with error -2 Fri Oct 28 02:01:35 2016 kern.warn kernel: [ 10.098492] ath10k_pci :01:00.0: Falling back to user helper Fri Oct 28 02:01:35 2016 kern.err kernel: [ 10.176500] firmware ath10k!pre-cal-pci-:01:00.0.bin: firmware_loading_store: map pages failed Fri Oct 28 02:01:35 2016 kern.info kernel: [ 10.677026] ath10k_pci :01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub : Fri Oct 28 02:01:35 2016 kern.info kernel: [ 10.686424] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1 Fri Oct 28 02:01:35 2016 kern.info kernel: [ 10.699498] ath10k_pci :01:00.0: firmware ver 10.2.4.70.58 api 5 features no-p2p,raw-mode,mfp crc32 e1af076f Fri Oct 28 02:01:35 2016 kern.warn kernel: [ 10.709932] ath10k_pci :01:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2 Fri Oct 28 02:01:35 2016 kern.warn kernel: [ 10.720531] ath10k_pci :01:00.0: Falling back to user helper Fri Oct 28 02:01:35 2016 kern.err kernel: [ 10.798719] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed Fri Oct 28 02:01:35 2016 kern.info kernel: [ 10.823845] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 Fri Oct 28 02:01:35 2016 kern.info kernel: [ 11.954723] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1 [...] // Evertyhing runs fine for a bit more than a day, but then this happens ... // // Note: The ath10k radio in question is wlan0 // Sat Oct 29 10:38:21 2016 daemon.info hostapd: wlan1: STA 9c:12:34:56:78:9a IEEE 802.11: disassociated Sat Oct 29 10:38:22 2016 daemon.info hostapd: wlan1: STA 9c:12:34:56:78:9a IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE) Sat Oct 29 10:42:57 2016 daemon.info hostapd: wlan1: STA 00:12:34:56:78:9a WPA: group key handshake
