Re: D.C. Circuit Upholds FCC 2020 Order in 5.9 GHz Band.
On 8/12/22 11:37 AM, Dave Taht wrote: any of our hw capable of using this new band? mtk7915 can use this if I understand properly (like channel 177?) https://github.com/greearb/linux-ct-5.19/commit/e73c819175f67096c5f82bdcc204a17643b681c5 Thanks, Ben -- Forwarded message - From: Louis Peraertz Date: Fri, Aug 12, 2022 at 11:27 AM Subject: [WISPAMembers] Court Victory! D.C. Circuit Upholds FCC 2020 Order in 5.9 GHz Band. To: Today, the United States Court of Appeals for the District of Columbia Circuit (D.C. Circuit) issued an opinion that is great news for WISPA operator members. It upheld the Federal Communications Commission’s (FCC) November 2020 Order and Further Notice of Proposed Rulemaking (FNPRM) that allocated 45 megahertz of spectrum for unlicensed use and 30 megahertz of spectrum for Cellular Vehicle-To-Everything (C-V2X) technologies. -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath10k_ct firmware crashes
On 1/18/22 4:29 AM, Koen Vandeputte wrote: Hi Ben, After stress testing some wave 1 2x2 radios on multiple boards using openwrt master I noticed this crash on 2 of them. Any idea? 01:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter Thanks, Koen [ 16.441327] ath10k 5.15 driver, optimized for CT firmware, probing pci device: 0x3c. [ 16.468523] ath10k_pci :01:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0 [ 17.719409] ath10k_pci :01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043222ff sub 19b6:d042 [ 17.728819] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1 tracing 0 dfs 1 testmode 0 [ 17.740820] ath10k_pci :01:00.0: firmware ver 10.1-ct-8x-__fH-022-ecad3248 api 2 features wmi-10.x,mfp,txstatus-noack,wmi-10.x-CT,ratemask-CT,txrate-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT crc32 1b2a161c [ 18.063728] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 [ 18.993270] ath10k_pci :01:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256 [ 19.011087] ath10k_pci :01:00.0: wmi print 'P 128 V 8 T 410' [ 19.017226] ath10k_pci :01:00.0: wmi print 'msdu-desc: 1424 sw-crypt: 0 ct-sta: 0' [ 19.025374] ath10k_pci :01:00.0: wmi print 'alloc rem: 25000 iram: 38944' [ 19.082086] ath10k_pci :01:00.0: htt-ver 2.2 wmi-op 2 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1 [ 19.097374] ath10k_pci :01:00.0: NOTE: Firmware DBGLOG output disabled in debug_mask: 0x1000 [ 19.228812] ath: EEPROM regdomain sanitized [ 19.228825] ath: EEPROM regdomain: 0x64 [ 19.228830] ath: EEPROM indicates we should expect a direct regpair map [ 19.228849] ath: Country alpha2 being used: 00 [ 19.228854] ath: Regpair used: 0x64 [ 19.282229] usbcore: registered new interface driver option [ 19.288009] usbserial: USB Serial support registered for GSM modem (1-port) [ 19.318937] usbcore: registered new interface driver qcserial [ 19.324852] usbserial: USB Serial support registered for Qualcomm USB modem [ 19.342601] qcserial 2-1:1.0: Qualcomm USB modem converter detected [ 19.349298] usb 2-1: Qualcomm USB modem converter now attached to ttyUSB0 [ 19.359080] qcserial 2-1:1.2: Qualcomm USB modem converter detected [ 19.365777] usb 2-1: Qualcomm USB modem converter now attached to ttyUSB1 [ 19.389826] qcserial 2-1:1.3: Qualcomm USB modem converter detected [ 19.396484] usb 2-1: Qualcomm USB modem converter now attached to ttyUSB2 [ 19.429616] kmodloader: done loading kernel modules from /etc/modules.d/* [ 26.341428] eth0: link up (1000Mbps/Full duplex) [ 26.346711] br-wan: port 1(eth0) entered blocking state [ 26.352077] br-wan: port 1(eth0) entered disabled state [ 26.357631] device eth0 entered promiscuous mode [ 26.375076] br-wan: port 1(eth0) entered blocking state [ 26.380431] br-wan: port 1(eth0) entered forwarding state [ 32.696768] ag71xx: max retries for SGMII fixup exceeded [ 32.702172] eth1: link up (1000Mbps/Full duplex) [ 32.727999] br-wan: port 2(eth1) entered blocking state [ 32.733310] br-wan: port 2(eth1) entered disabled state [ 32.738882] device eth1 entered promiscuous mode [ 32.808555] br-wan: port 2(eth1) entered blocking state [ 32.813867] br-wan: port 2(eth1) entered forwarding state [ 37.660591] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [ 85.293759] ath10k_pci :01:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256 [ 85.311655] ath10k_pci :01:00.0: wmi print 'P 128 V 8 T 410' [ 85.317869] ath10k_pci :01:00.0: wmi print 'msdu-desc: 1424 sw-crypt: 0 ct-sta: 0' [ 85.326004] ath10k_pci :01:00.0: wmi print 'alloc rem: 25000 iram: 38944' [ 85.398523] ath10k_pci :01:00.0: pdev param 0 not supported by firmware [ 85.413584] ath10k_pci :01:00.0: rts threshold -1 [ 85.428114] device wlan0 entered promiscuous mode [ 85.435115] device wlan0 left promiscuous mode [ 5578.497296] ath10k_pci :01:00.0: Failed to synchronize setup for vdev 0 restart 0: -145, will restart firmware [ 5578.507831] ath10k_pci :01:00.0: failed to start vdev 0 addr 00:00:00:00:00:00 on freq 5320: -145 [ 5578.518005] ath10k_pci :01:00.0: firmware crashed! (guid b696878d-15a0-434c-9d17-81052d629e31) Firmware/hardware hung, so we faked a crash to restart it. I doubt I can do anything to fix/improve this. I assume the radio's came back up OK after they crashed? In general, wave-2 ath10k-ct seems more stable if you have a choice. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Help with WiFi Streaming (ie noack) mode.
On 9/11/21 5:08 PM, Nick Dennis wrote:
("WiFi Streaming" is just a more descriptive name for the desired wifi
behaviour.
The wifi keeps streaming packets without waiting for ACKS/Block ACKs.)
I'm working with ath10k-ct, the boot announceent shows:
[ 17.250943] ath10k_pci :00:00.0: qca988x hw2.0 target 0x4100016c chip_id
0x043222ff sub :
[ 17.260370] ath10k_pci :00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs
1 testmode 0
[ 23.753344] ath10k_pci :00:00.0: firmware ver 10.1-ct-8x-__fH-022-ecad3248 api 2 features
wmi-10.x,mfp,txstatus-noack,wmi-10.x-CT,ratemask-CT,txrate-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT crc32
1b2a161c
In noack mode, rate control algorithms won't know whether a packet transmission
was successful or not, so a fixed rate has to be set, normally with only 1 try.
So far, I've patched mac80211 and ath10k-ct so that
root@Openwrt:/#iw dev wlan0 set bitrates ht-mcs-5 vht-mcs-5 1:9 2:9 sgi-5
sets a single rate bit in the ath10k_vif bitrate_mask.control[ band ].vht_mcs[
0 ]
and
root@Openwrt:/#iw wlan0 set noack_map 0x00ff
sets the ieee80211_tx_info flag IEEE80211_TX_CTL_NO_ACK for data packets.
Also needed a patch to ath10k function ath10k_htt_tx_32 for the fixed rate to
show in the gui association list
- detect info->flags & IEEE80211_TX_CTL_NO_ACK and
- set the variables pream_type, nss, mcs and num_retries from ath10k_vif
- which then set up txbuf->cmd_tx.peerid.
While running iperf across a link:
- setting the fixed rate causes the throughput to change accordingly
- but setting the noack_map causes
-- the rate shown on the gui to drop from 400 to 173 Mbps
-- packets stop being aggregated.
so the throughput drops from about 200 Mbps to about 80 Mbps
What am i missing?
Not sure, but maybe try leaving rate-control and rest of the stack alone.
Instead use ath10k 'set_rate_overrides'
debugfs to set rate as you wish and disable retries?
Thanks,
Ben
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: FRAG Attacks (new vuln for wifi)
On 5/13/21 11:50 AM, Mirko Parthey wrote:
On Thu, May 13, 2021 at 03:49:05PM +0200, Felix Fietkau wrote:
We're talking about the version of the kernel tree used to create the
ath10k-ct source, not the kernel version used by OpenWrt.
OK, sorry for the noise.
I have compile-tested (against upstream stable kernels) 4.19, 5.4
and 5.10 ath10k-ct driver versions. I have not tested this in owrt,
so if someone has time to pull this in and do some testing I'd
be grateful.
Thanks,
Ben
https://github.com/greearb/ath10k-ct
commit b44cd7b2e7b0df5995ece18f358d4dfc40834ba1 (HEAD -> master, origin/master)
Author: Ben Greear
Date: Thu Jun 3 13:29:23 2021 -0700
ath10k-ct: Add security fixes.
For 4.19, 5.4, and 5.10 kernels. This rebases -ct changes
on top of upstream stable kernel's latest code. Including
the wifi security fixes that recently went in.
Signed-off-by: Ben Greear
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH] ath10k-ct: backport upstream fixes for FragAttacks
I am aware, just haven't had time to work on it yet. Thanks, Ben On 5/27/21 4:05 AM, Nick Lowe wrote: Hi Hauke, I wonder if it is worth also opening an issue for this over at https://github.com/greearb/ath10k-ct/issues ? Best, Nick ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: FRAG Attacks (new vuln for wifi)
On 5/12/21 9:00 AM, Felix Fietkau wrote: Hi, On 2021-05-12 01:34, Paul D wrote: https://www.fragattacks.com/ https://lore.kernel.org/linux-wireless/20210511180259.159598-1-johan...@sipsolutions.net/ I've merged those fixes in openwrt commit 025bd93f36c9. After some testing in master, we should backport them soon. ath10k-ct will need to be fixed too, and I plan on pushing an mt76 fix very soon. Not sure what other drivers may need fixing... - Felix Regarding ath10k-ct, what kernel-versions of the ath10k-ct driver need to be patched? Is 4.19 the oldest that owrt will consume? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath10k-ct all hash values are different?
On 1/14/21 10:05 AM, Ben Greear wrote: On 1/13/21 4:58 PM, Sven Roederer wrote: Ben, seems to me, that at least "firmware-5-ct-full-community-12.bin-lede.013" is still not recovered. File is there, but contains only 0x00. This seems to cause my fresh build of 19.07.5 to fail. Yes, I verified that 9980 firmware is not recovered. I'm not sure we have any local copy of that old file. Maybe someone else that has compiled this in the past has a working copy they could send me to repopulate my web server? If my grep is correct, these files are also corrupted, so if someone has these cached somewhere, please send these to me I'll get them re-populated as well. [greearb@ww2 downloads]$ find . -name "firmware-*lede*" -print|xargs grep -L ATH10 ./firmware-2-ct-full-htt-mgt-community-22.bin.lede.020 ./firmware-2-ct-full-community-22.bin.lede.003 ./ath10k-9984-10-4b/firmware-5-ct-full-community-12.bin-lede.016 ./ath10k-9984-10-4b/firmware-5-ct-full-community-12.bin-lede.020 ./ath10k-9984-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.020 ./ath10k-9984-10-4b/firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.020 ./ath10k-9984-10-4b/firmware-5-ct-htt-mgt-community-12.bin-lede.020 ./ath10k-9984-10-4b/firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.021 ./ath10k-9984-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.016 ./ath10k-9984-10-4/firmware-5-ct-full-community-7.bin-lede.001 ./ath10k-9984-10-4/firmware-5-ct-full-community-8.bin-lede.006 ./ath10k-9984-10-4/firmware-5-ct-full-community-7.bin-lede.004 ./ath10k-9984-10-4/firmware-5-ct-full-community-9.bin-lede.003 ./firmware-2-ct-full-htt-mgt-community-22.bin.lede.003 ./firmware-2-ct-full-community-22.bin.lede.016 ./ath10k-9887/firmware-2-ct-full-htt-mgt-community-22.bin.lede.020 ./ath10k-9887/firmware-2-ct-full-community-22.bin.lede.020 ./ath10k-9887/firmware-2-ct-full-htt-mgt-community-22.bin.lede.004 ./ath10k-9887/firmware-2-ct-full-community-22.bin.lede.004 ./firmware-2-ct-full-community-22.bin.lede.020 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.006 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.012 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.007 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.016 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.020 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.008 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.001 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.020 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.003 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.018 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.002 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.005 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.003 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.013 ./ath10k-10-4b/firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.020 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.009 ./ath10k-10-4b/firmware-5-ct-htt-mgt-community-12.bin-lede.020 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.010 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.015 ./ath10k-10-4b/firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.021 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.017 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.016 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.014 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.007 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.004 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.018 ./ath10k-10-4b/firmware-5-ct-htt-mgt-community-12.bin-lede.018 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.005 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.002 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.014 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.004 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.011 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.011 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.012 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.017 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.013 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.006 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.001 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.010 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.008 ./ath10k-10-4b/firmware-5-ct-full-community-12.bin-lede.009 ./ath10k-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.015 ./firmware-2-ct-full-community.bin-18.rc1-lede ./ath10k-9888-10-4b/firmware-5-ct-full-community-12.bin-lede.016 ./ath10k-9888-10-4b/firmware-5-ct-full-community-12.bin-lede.020 ./ath10k-9888-10-4b/firmware-5-ct-full-htt-mgt-community-12.bin-lede.020 ./ath10k-98
Re: ath10k-ct all hash values are different?
On 1/13/21 4:58 PM, Sven Roederer wrote: Ben, seems to me, that at least "firmware-5-ct-full-community-12.bin-lede.013" is still not recovered. File is there, but contains only 0x00. This seems to cause my fresh build of 19.07.5 to fail. Yes, I verified that 9980 firmware is not recovered. I'm not sure we have any local copy of that old file. Maybe someone else that has compiled this in the past has a working copy they could send me to repopulate my web server? Thanks, Ben + curl -f --connect-timeout 20 --retry 5 --location --insecure https:// www.candelatech.com/downloads/ath10k-10-4b/firmware-5-ct-full- community-12.bin-lede.013 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 548k 100 548k0 0 985k 0 --:--:-- --:--:-- --:--:-- 985k Hash of the downloaded file does not match (file: 6a95c4323e008499af8d3549513c8a128c69b97296888a4c4b642e6c14a65508, requested: 6fa74a3fc87cba97dbc4a7213b760f8d997cd9c5f11900d47d387b23764cf20a) - deleting download. Can you check please? Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: New ath10k-ct driver available
On 12/28/20 2:11 PM, Hauke Mehrtens wrote: On 12/24/20 10:28 PM, Ben Greear wrote: I just pushed this commit. I'm interested in feedback if anyone tests it. It could fix some of the strange tx issues, and for the 5.10 kernel, at least, it fixes very obvious tx-path issues. commit b753e8bf22b94297acbaa370b4cb0be87e3da4b8 (HEAD -> master, origin/master) Author: Ben Greear Date: Thu Dec 24 13:24:42 2020 -0800 ath10k-ct: Fix invalid use of ath-cb struct. This fixes some cases where -ct firmware would attempt to transmit a fixed-rate frame, thinking the packet was injected, when in fact it was not. Align the ath-cb pointers on 8-byte boundaries, which may give a minor performance boost. 5.4 kernels and higher are modified, I'll check on older kernels later. Signed-off-by: Ben Greear Hi, This change is integrated in OpenWrt master: https://git.openwrt.org/da9beb070d112469adeb30dd79dcde3176bfb290 Should we backport this change https://github.com/greearb/ath10k-ct/commit/b753e8bf22b94297acbaa370b4cb0be87e3da4b8 to ath10k-ct 4.19 for the openwrt 19.07 stable branch? I think 4.19 will be OK as is, because the ieee80211_tx_info->control.flags is at offset 32, and the sizeof ath10k_skb_cb is 28, so the ath10k skb portion should never overwrite the control.flags. Thanks, Ben Hauke -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
New ath10k-ct driver available
I just pushed this commit. I'm interested in feedback if anyone tests it. It could fix some of the strange tx issues, and for the 5.10 kernel, at least, it fixes very obvious tx-path issues. commit b753e8bf22b94297acbaa370b4cb0be87e3da4b8 (HEAD -> master, origin/master) Author: Ben Greear Date: Thu Dec 24 13:24:42 2020 -0800 ath10k-ct: Fix invalid use of ath-cb struct. This fixes some cases where -ct firmware would attempt to transmit a fixed-rate frame, thinking the packet was injected, when in fact it was not. Align the ath-cb pointers on 8-byte boundaries, which may give a minor performance boost. 5.4 kernels and higher are modified, I'll check on older kernels later. Signed-off-by: Ben Greear -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath10k-ct all hash values are different?
I think I fixed it all on our web page, let me know if otherwise. Thanks, Ben On 11/9/20 1:42 AM, Nick wrote: Can we somehow get to the same naming convention, again? In OpenWrt it is: QCA998X-firmware-... directly in /. On the ct server it is QCA998X/firmware-...? Bests, Nick On 11/8/20 10:55 PM, Ben Greear wrote: I tried to copy them all back into place...could have made mistakes since owrt names them differently than what is on my web server. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath10k-ct all hash values are different?
I tried to copy them all back into place...could have made mistakes since owrt names them differently than what is on my web server. Please try some older builds for various firmware and let me know if there are still issues. Thanks, Ben On 11/8/20 9:49 AM, Baptiste Jonglez wrote: Hi, All versions of the firmware are mirrored here http://sources.openwrt.org/ It's just that the build system somehow fails to fallback to this mirror like it does for regular downloads (in other words: it's a bug) Ben, could you re-upload all versions so that older builds can still work? This should work: wget -r --accept-regex "/QCA*" "http://sources.openwrt.org/"; Thanks, Baptiste On 08-11-20, Ben Greear wrote: I have uploaded latest, please see if this works. greearb@ww2 downloads]$ ~/bin/fw_lede.bash 988x H988XFC=398e4380e7e55105f3da0f78af29d1e437404ed3a82597aa4b6daaa7dce1a38e firmware-2-ct-full-community-22.bin.lede.022 H988XFCH=990d9cbf79dd81f141257a289f89808bd7726406c9ed845a7e49e5167002ffde firmware-2-ct-full-htt-mgt-community-22.bin.lede.022 /home/greearb/candela_html/downloads 9887 H9887FC=a526cb44560da569781e10bf608194b1eff29b250e9887dba6d4d9a15c921c1e firmware-2-ct-full-community-22.bin.lede.022 H9887FCH=0b60fc558b773e9cbd5c2df903c894a030872fdb96390b0cca4b23b7fc7b881f firmware-2-ct-full-htt-mgt-community-22.bin.lede.022 /home/greearb/candela_html/downloads 9980 H9980FC=578ad67976b61a393eb820a05e8eae70ec95f6b803bedbe952b8ff573eb09abe firmware-5-ct-full-community-12.bin-lede.022 H9980FCH=8ea5c9f27c048796d406706a9c8471cd070f5aeb768622bb334a04853d557a4d firmware-5-ct-full-htt-mgt-community-12.bin-lede.022 H9980CH=7b0b7545114e8dc0f2c70dc8a43a5a48d84d37f2a4673977a692c5f3361445c6 firmware-5-ct-htt-mgt-community-12.bin-lede.022 H9980FHQ=267b4f435cf10eeefb9f7ee1bd574fd8ec6b4d8cfc007d7f8c95852d0332 firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.022 /home/greearb/candela_html/downloads 9984 H9984FC=7bfe5bf7c38532fa57db62ebc56ec625583928d5d4736475d5dec4d4ae031154 firmware-5-ct-full-community-12.bin-lede.022 H9984FCH=672be40c4d987d7e8e309341262a37cda7baf925416d1dc651284b6d2bd30969 firmware-5-ct-full-htt-mgt-community-12.bin-lede.022 H9984CH=a24e887f13aca4358ab2b6a42a7212d066e4d19e29b00bb26f9681b1dc8d0eb0 firmware-5-ct-htt-mgt-community-12.bin-lede.022 H9984FHQ=dbdfd3fdf8c3b43b7aa1b487c5269169845c221cb8dfaad1a0a133951482e221 firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.022 /home/greearb/candela_html/downloads 4019 H4019FC=503956d9bf09d603e4cf36ac080fa5b5a22032166204e3c15ae898647bc50df3 firmware-5-ct-full-community-12.bin-lede.022 H4019FCH=591bf9ed00fb540d7ba034453f17696e8dd91a4b7d81f7cc1ec41f447fa74831 firmware-5-ct-full-htt-mgt-community-12.bin-lede.022 H4019CH=06e58a283ff90d021ff7cb58684cbf39750bd71cf91c56b32add64253133929c firmware-5-ct-htt-mgt-community-12.bin-lede.022 H4019FHQ=16c4bcadc97425428773826bb1e72005508a2535e0c54954f4d852a744abb298 firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.022 /home/greearb/candela_html/downloads 9888 H9888FC=82ff5afcf0c9dcdb03b0b40c6eddc81e11b18e4f522f681935b5ec42537972ee firmware-5-ct-full-community-12.bin-lede.022 H9888FCH=1a741f2cf43fbea24ed831b4e76cbb114b525d1ee9b917ce916cbcc42f92 firmware-5-ct-full-htt-mgt-community-12.bin-lede.022 H9888CH=34bf07912a2f3fce4a5887c690848bb06d339bd1c86541b0b57b9c45eccc88e4 firmware-5-ct-htt-mgt-community-12.bin-lede.022 H9888FHQ=983deaa2bf71b48a48fde534b8c325f7ec0ecaf9a76be43ca36b4e52614b3e55 firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.022 /home/greearb/candela_html/downloads Thanks, Ben On 11/7/20 1:40 PM, Nick wrote: It is the firmware that is broken and just contains 0s. On 11/7/20 6:54 PM, Nick wrote: I fixed the hash values: https://github.com/openwrt/openwrt/pull/3573 Not sure why the hash is suddenly different for all firmware files? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath10k-ct all hash values are different?
I have uploaded latest, please see if this works. greearb@ww2 downloads]$ ~/bin/fw_lede.bash 988x H988XFC=398e4380e7e55105f3da0f78af29d1e437404ed3a82597aa4b6daaa7dce1a38e firmware-2-ct-full-community-22.bin.lede.022 H988XFCH=990d9cbf79dd81f141257a289f89808bd7726406c9ed845a7e49e5167002ffde firmware-2-ct-full-htt-mgt-community-22.bin.lede.022 /home/greearb/candela_html/downloads 9887 H9887FC=a526cb44560da569781e10bf608194b1eff29b250e9887dba6d4d9a15c921c1e firmware-2-ct-full-community-22.bin.lede.022 H9887FCH=0b60fc558b773e9cbd5c2df903c894a030872fdb96390b0cca4b23b7fc7b881f firmware-2-ct-full-htt-mgt-community-22.bin.lede.022 /home/greearb/candela_html/downloads 9980 H9980FC=578ad67976b61a393eb820a05e8eae70ec95f6b803bedbe952b8ff573eb09abe firmware-5-ct-full-community-12.bin-lede.022 H9980FCH=8ea5c9f27c048796d406706a9c8471cd070f5aeb768622bb334a04853d557a4d firmware-5-ct-full-htt-mgt-community-12.bin-lede.022 H9980CH=7b0b7545114e8dc0f2c70dc8a43a5a48d84d37f2a4673977a692c5f3361445c6 firmware-5-ct-htt-mgt-community-12.bin-lede.022 H9980FHQ=267b4f435cf10eeefb9f7ee1bd574fd8ec6b4d8cfc007d7f8c95852d0332 firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.022 /home/greearb/candela_html/downloads 9984 H9984FC=7bfe5bf7c38532fa57db62ebc56ec625583928d5d4736475d5dec4d4ae031154 firmware-5-ct-full-community-12.bin-lede.022 H9984FCH=672be40c4d987d7e8e309341262a37cda7baf925416d1dc651284b6d2bd30969 firmware-5-ct-full-htt-mgt-community-12.bin-lede.022 H9984CH=a24e887f13aca4358ab2b6a42a7212d066e4d19e29b00bb26f9681b1dc8d0eb0 firmware-5-ct-htt-mgt-community-12.bin-lede.022 H9984FHQ=dbdfd3fdf8c3b43b7aa1b487c5269169845c221cb8dfaad1a0a133951482e221 firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.022 /home/greearb/candela_html/downloads 4019 H4019FC=503956d9bf09d603e4cf36ac080fa5b5a22032166204e3c15ae898647bc50df3 firmware-5-ct-full-community-12.bin-lede.022 H4019FCH=591bf9ed00fb540d7ba034453f17696e8dd91a4b7d81f7cc1ec41f447fa74831 firmware-5-ct-full-htt-mgt-community-12.bin-lede.022 H4019CH=06e58a283ff90d021ff7cb58684cbf39750bd71cf91c56b32add64253133929c firmware-5-ct-htt-mgt-community-12.bin-lede.022 H4019FHQ=16c4bcadc97425428773826bb1e72005508a2535e0c54954f4d852a744abb298 firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.022 /home/greearb/candela_html/downloads 9888 H9888FC=82ff5afcf0c9dcdb03b0b40c6eddc81e11b18e4f522f681935b5ec42537972ee firmware-5-ct-full-community-12.bin-lede.022 H9888FCH=1a741f2cf43fbea24ed831b4e76cbb114b525d1ee9b917ce916cbcc42f92 firmware-5-ct-full-htt-mgt-community-12.bin-lede.022 H9888CH=34bf07912a2f3fce4a5887c690848bb06d339bd1c86541b0b57b9c45eccc88e4 firmware-5-ct-htt-mgt-community-12.bin-lede.022 H9888FHQ=983deaa2bf71b48a48fde534b8c325f7ec0ecaf9a76be43ca36b4e52614b3e55 firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.022 /home/greearb/candela_html/downloads Thanks, Ben On 11/7/20 1:40 PM, Nick wrote: It is the firmware that is broken and just contains 0s. On 11/7/20 6:54 PM, Nick wrote: I fixed the hash values: https://github.com/openwrt/openwrt/pull/3573 Not sure why the hash is suddenly different for all firmware files? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
New ath10k-ct driver available
Hello, On June 30, I pulled in an upstream commit that changed dma_burst. This broke at least some systems (see: https://github.com/greearb/ath10k-ct/issues/153) I am not sure how to detect which value to use in the driver, it seems platform dependent from what little I know of the problem. So, I'm adding a fwcfg option to override the dma_burst option. Here is the new ath10k-ct commit ID. If someone can pull this in a do a bit of testing I'd appreciate it. Bug 153 has some details on how to configure the override if you want to try that. commit 76280f692492fb9ddd506bddffab76efd2a57312 (HEAD -> master, origin/master) Author: Ben Greear Date: Wed Sep 16 14:31:42 2020 -0700 ath10k-ct: Allow override of dma_burst setting using fwcfg. Previously tested and shown to work on 5.4 kernel, now applied to 4.16 through 5.8 kernels. Signed-off-by: Ben Greear Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
New ath10k-ct driver available
Hello, On June 30, I pulled in an upstream commit that changed dma_burst. This broke at least some systems (see: https://github.com/greearb/ath10k-ct/issues/153) I am not sure how to detect which value to use in the driver, it seems platform dependent from what little I know of the problem. So, I'm adding a fwcfg option to override the dma_burst option. Here is the new ath10k-ct commit ID. If someone can pull this in a do a bit of testing I'd appreciate it. Bug 153 has some details on how to configure the override if you want to try that. commit 76280f692492fb9ddd506bddffab76efd2a57312 (HEAD -> master, origin/master) Author: Ben Greear Date: Wed Sep 16 14:31:42 2020 -0700 ath10k-ct: Allow override of dma_burst setting using fwcfg. Previously tested and shown to work on 5.4 kernel, now applied to 4.16 through 5.8 kernels. Signed-off-by: Ben Greear Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Updated ath10k-ct firmware
Here are md5sums and details for latest firmware images. The 'qcache' variant enables the qcache logic like upstream firmware uses. It appears to have fixed on user's problems, but I am not sure it is an over-all improvement. It may allow more stations to associate in AP mode, if you tune fwcfg properly, but I have not tested that and don't know how well it performs. qcache in general swaps firmware memory objects in and out out of host memory, so it will at the least use more host memory. Since last time: wave-1: single extra line of debugging code, no significant change. wave-2: * Enable qcache builds * Tune memory in 4019 chipset firmware to allow more TIDs (at cost of fewer stations) This should balance better and have less chance of crashing system under high stations loads. 988x a4c3d1e2fb80f6b8b9738c7189795ab9505e6c09efc12ba5f08ee7f49e934239 firmware-2-ct-full-community-22.bin.lede.020 93108bd0870652860cdb57749f5a12205ecb15bb1f129d916ad73b6f06406c82 firmware-2-ct-full-htt-mgt-community-22.bin.lede.020 /home/greearb/candela_html/downloads 9887 459692deb186a63ab8eeddb7ad5d54779266e68ca686e7c46062554db6dca12b firmware-2-ct-full-community-22.bin.lede.020 fd126a457d0927d0c8ea10d66ef5b67d5e1e0741f8692bb3016bb602d0af3098 firmware-2-ct-full-htt-mgt-community-22.bin.lede.020 /home/greearb/candela_html/downloads 9980 59f4b1b9377d14cf73e2ccc024b51ed906939432bfb45a518b4e7696aedca136 firmware-5-ct-full-community-12.bin-lede.020 c1a660f3d388e4500283c1ea99cda08d3d43e20178c676b6bbbcdc53f7864372 firmware-5-ct-full-htt-mgt-community-12.bin-lede.020 be5a5f8059d9af65bb86f13df11408707b7611661d231bc2a8a98681c8947dd5 firmware-5-ct-htt-mgt-community-12.bin-lede.020 47ead9df5c3629a20b6464d0831179508713a57ca618c68ef598a5c728cf5a03 firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.020 /home/greearb/candela_html/downloads 9984 b30cc6859395d176006a2ccf170dcd786e2a466f360648f546808c6f3827bc1d firmware-5-ct-full-community-12.bin-lede.020 ce59caa48a390138c9d059f796200ebd1c01e3e054b031c1abe55751a1410c55 firmware-5-ct-full-htt-mgt-community-12.bin-lede.020 42d070e9be6a0d85958516380d009de188a6766d31713af54b3c500d2f365d10 firmware-5-ct-htt-mgt-community-12.bin-lede.020 97cd148e89a39d4bb21749307b134a08202faaf832e61d5073b73d832d2fa654 firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.020 /home/greearb/candela_html/downloads 4019 4326484653b3cb6d992b871cdabcb0a64bfd15d0ee5c0da4f19c1c87716efe3a firmware-5-ct-full-community-12.bin-lede.020 062b265102b0b293638073886f2273961277a97e298e131d5efbdd46ebaaa154 firmware-5-ct-full-htt-mgt-community-12.bin-lede.020 01c7825a816a4c97e518a26b3913608782b970dcac568857fdc3529450e75ff7 firmware-5-ct-htt-mgt-community-12.bin-lede.020 cd4949e1199400a98e9010ea9fc13922a2ae774e9d28b36fa4af315aef11a9cf firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.020 /home/greearb/candela_html/downloads 9888 e3c381843688e2d2a11c0ad1e1e26be499fd66f646deaa75e0f1b0cf3c4893b7 firmware-5-ct-full-community-12.bin-lede.020 ad0e206d01f936d09e45b40088422415e54a7665fc7cdcd111659ee415045168 firmware-5-ct-full-htt-mgt-community-12.bin-lede.020 b8f587092fe69c23c6555bfa1c817304920c2bab8408b32b3ff1ef3f56250bc8 firmware-5-ct-htt-mgt-community-12.bin-lede.020 b569c96eebcfd83d154453743f5c4f4492f033bcc8b0b6ee221b5ca419fe051f firmware-5-ct-htt-mgt-community-qcache-12.bin-lede.020 /home/greearb/candela_html/downloads Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 19.07 7/8] ath10k-ct-firmware: add htt-mgt variants
ldPackage,ath10k-firmware-qca9888-ct-htt)) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
New ath10k-ct firmware
Not a large change from last time, but should fix at least one rare wave-2 crash. The htt-mgt-community builds are trimmed for supporting lots of stations (typically 150+ stations per radio). [greearb@ww2 downloads]$ ~/bin/fw_lede.bash 988x 8b4c99253aa309d35f2e060c190091b8db1b84dbda06a6a15c83ac0f9a938126 firmware-2-ct-full-community-22.bin.lede.019 a7168916d6aa5e4d7858f8b620c0c980c76d03f390929db6f4077685ce2051e7 firmware-2-ct-full-htt-mgt-community-22.bin.lede.019 /home/greearb/candela_html/downloads 9887 459692deb186a63ab8eeddb7ad5d54779266e68ca686e7c46062554db6dca12b firmware-2-ct-full-community-22.bin.lede.019 fd126a457d0927d0c8ea10d66ef5b67d5e1e0741f8692bb3016bb602d0af3098 firmware-2-ct-full-htt-mgt-community-22.bin.lede.019 /home/greearb/candela_html/downloads 9980 7dc934f934bc4973c9273a4f22cfead8e26ec6f579647af31b718a860eca0a4b firmware-5-ct-full-community-12.bin-lede.019 71a27b245a382fe009938d2826d5c97a90dceb10ddf638325268df91837ea302 firmware-5-ct-full-htt-mgt-community-12.bin-lede.019 9ed4fe41e5b0f30172f71ae0fe382dc0aab8aa4f8a898417af4f7ee936575ef6 firmware-5-ct-htt-mgt-community-12.bin-lede.019 /home/greearb/candela_html/downloads 9984 32d13f432691fe759ded7d027052e925233adb436cd8f729f85ec3d19ccd1dfd firmware-5-ct-full-community-12.bin-lede.019 e8ab69777bd00b5fc6b1b7acccb55b903553a99932a5b0351602b5f690106588 firmware-5-ct-full-htt-mgt-community-12.bin-lede.019 74449b303b626e0713b3fd4f2d6103d65859403b2dd7bdd8882aa772b69b59c7 firmware-5-ct-htt-mgt-community-12.bin-lede.019 /home/greearb/candela_html/downloads 4019 4b89763087c7ed9b56046c4e621b7f045e452436d8d9b430a5d171179e313592 firmware-5-ct-full-community-12.bin-lede.019 fba591e5777c53b82542ba16cae69d9bb4684837f2fa4cee1b9b26f648096748 firmware-5-ct-full-htt-mgt-community-12.bin-lede.019 0d534c3c424184b8ec2773f15c8933bdab0d39b6f664d2578c6602b0eb7035d1 firmware-5-ct-htt-mgt-community-12.bin-lede.019 /home/greearb/candela_html/downloads 9888 048f4300725e6ebbf94a6bf4f3f4e4592c446fcdbe1d801aaac024b15e89e0c9 firmware-5-ct-full-community-12.bin-lede.019 d2a7e9fea6bd854721b3fc03a3a00d379d303b2bce339377ee87a1c14a60312d firmware-5-ct-full-htt-mgt-community-12.bin-lede.019 e52a6db33347c641ee791fd9a3a57a2503cdda1adc6b8d943e336431528b9d2a firmware-5-ct-htt-mgt-community-12.bin-lede.019 /home/greearb/candela_html/downloads Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Please pull latest ath10k-ct driver
Hello, Petr added a fix for spurious splat that has bothered people for a while. And, I added a patch that throttles the wake-queue logic. This significantly helps CPU usage in certain high-throughput test cases. If someone could update OpenWrt to pull the latest, I'd appreciate it. commit 3637be6f6baf99e85a7f0b27f80a99a2f2a5f78d Git commit IDs and recent change logs are below. Thanks, Ben [greearb@ben-dt4 ath10k-ct]$ git log commit 3637be6f6baf99e85a7f0b27f80a99a2f2a5f78d (HEAD -> master, origin/master) Author: Ben Greear Date: Wed Apr 29 08:30:39 2020 -0700 ath10k-ct: Add Petr Stetiar's splat-fixing patch. And for 5.4, add tx-queue-wake throttling patch. commit ae600d64fe9930d5397e7194f9b3eb6bf64474f9 Merge: 5ef6fd5 c1b6fa6 Author: Ben Greear Date: Wed Apr 29 07:54:23 2020 -0700 Merge pull request #129 from ynezz/upstream/workaround-invalid-tx-rate ath10k-ct: workaround TX rate code firmware bug commit c1b6fa6475a4141d27eb481e508196a862c2d64d Author: Petr Štetiar Date: Tue Apr 28 19:58:54 2020 +0200 ath10k-ct: workaround TX rate code firmware bug It seems, that we get a bad tx/rx rate from firmware, it is not a real problem so just check for invalid rate (0xff) and force it to be zero instead. Fixes: #117 Ref: https://bugs.openwrt.org/index.php?do=details&task_id=3055 Signed-off-by: Petr Štetiar -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] New ath10k-ct firmware available.
Hello, I looked at this briefly and it looks OK to me. I did not test it out though. Thanks, Ben On 04/26/2020 05:26 AM, Álvaro Fernández Rojas wrote: Hi Ben, I've renamed the old full-htt-mgt firmwares and added the new ones as htt-mgt. This way the user can choose between both of them: https://github.com/openwrt/openwrt/pull/2963 Best regards, Álvaro. El 24/04/2020 a las 20:48, Ben Greear escribió: For the wave-2, there is now a new variant: htt-mgt-community (vs the old full-htt-mgt-community) the non-full one (hence forth 'diet') compiles out a lot of firmware features that ath10k does not use (and/or which I consider unimportant). This saves a lot of resources and lets one configure more stations/vdevs/etc using fwcfg. I also tuned the 9886/8 and 4019 firmware to make better use of memory. With proper fwcfg, the 9888 supports 200 stations and the 4019 supports 162. I have not yet fully tested this of course, but will be doing so over the coming days. I did previously test 228 total stations on a Linksys MR8300 (aka EA8300) and it did fine in a torture test. My suggestion is to use the diet compile in place of the 'full-htt-mgt' one, but another option is to give the user another option to pick they file they want in the openwrt makefile. I am hoping someone will be able to do the openwrt patch, here is the raw info below. 988x 8b4c99253aa309d35f2e060c190091b8db1b84dbda06a6a15c83ac0f9a938126 firmware-2-ct-full-community-22.bin.lede.018 a7168916d6aa5e4d7858f8b620c0c980c76d03f390929db6f4077685ce2051e7 firmware-2-ct-full-htt-mgt-community-22.bin.lede.018 /home/greearb/candela_html/downloads 9887 459692deb186a63ab8eeddb7ad5d54779266e68ca686e7c46062554db6dca12b firmware-2-ct-full-community-22.bin.lede.018 fd126a457d0927d0c8ea10d66ef5b67d5e1e0741f8692bb3016bb602d0af3098 firmware-2-ct-full-htt-mgt-community-22.bin.lede.018 /home/greearb/candela_html/downloads 9980 cf26eb37524de54af51fe9b2efffc85e0e70ab849e8607ef63ce5a8ecffeaa42 firmware-5-ct-full-community-12.bin-lede.018 e9737538d7379e13ad4e4c8c519a63659b5e34a35455ed9ac4399ae8097caabc firmware-5-ct-full-htt-mgt-community-12.bin-lede.018 4d4f74afca487d452f244cd48304cf9710d8941eb97a6346a949ed6b6877d657 firmware-5-ct-htt-mgt-community-12.bin-lede.018 /home/greearb/candela_html/downloads 9984 a6b3d66efe640a430a837f238e91eddcd423eed6b887d3ae19716d87a71fd0b1 firmware-5-ct-full-community-12.bin-lede.018 96060227e372b3b210badccbe6b0bd75d9a35335a7a0f2966964e9e89f66b00f firmware-5-ct-full-htt-mgt-community-12.bin-lede.018 ee593fb5724d75c372de02ac7894e1630ee9f909fcb2e2bbf17aadef67cb9d43 firmware-5-ct-htt-mgt-community-12.bin-lede.018 /home/greearb/candela_html/downloads 4019 46d8f8f1e780813299dc8780eedcfceda103c6b4d8908589ad1adbef921714c0 firmware-5-ct-full-community-12.bin-lede.018 d884624fc34f4b5de7a3ec0534627c46cea25fca45657f3a2f6bb85f6c5893d7 firmware-5-ct-full-htt-mgt-community-12.bin-lede.018 51fe06f66365771647d16039cca8b541de3d642c45271977a4cfd433c2c5d45b firmware-5-ct-htt-mgt-community-12.bin-lede.018 /home/greearb/candela_html/downloads 9888 d01f1429aaf0bfac07eee3547e5821d19136840b2f983e75e76979a5ac19b6f0 firmware-5-ct-full-community-12.bin-lede.018 68c42f8e0dcf77f18d4813ac93174bf06ff5cf5aa4f69befe7f35f9fae1de1e3 firmware-5-ct-full-htt-mgt-community-12.bin-lede.018 6c692141155f5bb74c0117553d5d48ff2aaba73bd4d5e90a5044a5e2ec0faab0 firmware-5-ct-htt-mgt-community-12.bin-lede.018 /home/greearb/candela_html/downloads Example fwcfg files for 9888 and 4019 using the diet htt mgt builds: root@OpenWrt:/lib/firmware/ath10k# cat fwcfg-pci-\:01\:00.0.txt # For 9888 vdevs = 8 peers = 202 active_peers = 202 stations = 202 rate_ctrl_objs = 7 regdom = 840 #fwname = firmware-5-htt-mgt-b.bin fwver = 5 nohwcrypt = 0 ct_sta_mode = 0 tx_desc = 2200 #max_nss = 3 tids = 450 skid_limit = 360 max_amsdus = 3 root@OpenWrt:/lib/firmware/ath10k# cat fwcfg-ahb-a00.wifi.txt vdevs = 8 peers = 164 active_peers = 164 stations = 164 rate_ctrl_objs = 7 regdom = 840 #fwname = firmware-5-htt-mgt-b.bin fwver = 5 nohwcrypt = 0 ct_sta_mode = 0 tx_desc = 2000 #max_nss = 3 tids = 260 skid_limit = 360 max_amsdus = 3 Thanks, Ben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New ath10k-ct firmware available.
For the wave-2, there is now a new variant: htt-mgt-community (vs the old full-htt-mgt-community) the non-full one (hence forth 'diet') compiles out a lot of firmware features that ath10k does not use (and/or which I consider unimportant). This saves a lot of resources and lets one configure more stations/vdevs/etc using fwcfg. I also tuned the 9886/8 and 4019 firmware to make better use of memory. With proper fwcfg, the 9888 supports 200 stations and the 4019 supports 162. I have not yet fully tested this of course, but will be doing so over the coming days. I did previously test 228 total stations on a Linksys MR8300 (aka EA8300) and it did fine in a torture test. My suggestion is to use the diet compile in place of the 'full-htt-mgt' one, but another option is to give the user another option to pick they file they want in the openwrt makefile. I am hoping someone will be able to do the openwrt patch, here is the raw info below. 988x 8b4c99253aa309d35f2e060c190091b8db1b84dbda06a6a15c83ac0f9a938126 firmware-2-ct-full-community-22.bin.lede.018 a7168916d6aa5e4d7858f8b620c0c980c76d03f390929db6f4077685ce2051e7 firmware-2-ct-full-htt-mgt-community-22.bin.lede.018 /home/greearb/candela_html/downloads 9887 459692deb186a63ab8eeddb7ad5d54779266e68ca686e7c46062554db6dca12b firmware-2-ct-full-community-22.bin.lede.018 fd126a457d0927d0c8ea10d66ef5b67d5e1e0741f8692bb3016bb602d0af3098 firmware-2-ct-full-htt-mgt-community-22.bin.lede.018 /home/greearb/candela_html/downloads 9980 cf26eb37524de54af51fe9b2efffc85e0e70ab849e8607ef63ce5a8ecffeaa42 firmware-5-ct-full-community-12.bin-lede.018 e9737538d7379e13ad4e4c8c519a63659b5e34a35455ed9ac4399ae8097caabc firmware-5-ct-full-htt-mgt-community-12.bin-lede.018 4d4f74afca487d452f244cd48304cf9710d8941eb97a6346a949ed6b6877d657 firmware-5-ct-htt-mgt-community-12.bin-lede.018 /home/greearb/candela_html/downloads 9984 a6b3d66efe640a430a837f238e91eddcd423eed6b887d3ae19716d87a71fd0b1 firmware-5-ct-full-community-12.bin-lede.018 96060227e372b3b210badccbe6b0bd75d9a35335a7a0f2966964e9e89f66b00f firmware-5-ct-full-htt-mgt-community-12.bin-lede.018 ee593fb5724d75c372de02ac7894e1630ee9f909fcb2e2bbf17aadef67cb9d43 firmware-5-ct-htt-mgt-community-12.bin-lede.018 /home/greearb/candela_html/downloads 4019 46d8f8f1e780813299dc8780eedcfceda103c6b4d8908589ad1adbef921714c0 firmware-5-ct-full-community-12.bin-lede.018 d884624fc34f4b5de7a3ec0534627c46cea25fca45657f3a2f6bb85f6c5893d7 firmware-5-ct-full-htt-mgt-community-12.bin-lede.018 51fe06f66365771647d16039cca8b541de3d642c45271977a4cfd433c2c5d45b firmware-5-ct-htt-mgt-community-12.bin-lede.018 /home/greearb/candela_html/downloads 9888 d01f1429aaf0bfac07eee3547e5821d19136840b2f983e75e76979a5ac19b6f0 firmware-5-ct-full-community-12.bin-lede.018 68c42f8e0dcf77f18d4813ac93174bf06ff5cf5aa4f69befe7f35f9fae1de1e3 firmware-5-ct-full-htt-mgt-community-12.bin-lede.018 6c692141155f5bb74c0117553d5d48ff2aaba73bd4d5e90a5044a5e2ec0faab0 firmware-5-ct-htt-mgt-community-12.bin-lede.018 /home/greearb/candela_html/downloads Example fwcfg files for 9888 and 4019 using the diet htt mgt builds: root@OpenWrt:/lib/firmware/ath10k# cat fwcfg-pci-\:01\:00.0.txt # For 9888 vdevs = 8 peers = 202 active_peers = 202 stations = 202 rate_ctrl_objs = 7 regdom = 840 #fwname = firmware-5-htt-mgt-b.bin fwver = 5 nohwcrypt = 0 ct_sta_mode = 0 tx_desc = 2200 #max_nss = 3 tids = 450 skid_limit = 360 max_amsdus = 3 root@OpenWrt:/lib/firmware/ath10k# cat fwcfg-ahb-a00.wifi.txt vdevs = 8 peers = 164 active_peers = 164 stations = 164 rate_ctrl_objs = 7 regdom = 840 #fwname = firmware-5-htt-mgt-b.bin fwver = 5 nohwcrypt = 0 ct_sta_mode = 0 tx_desc = 2000 #max_nss = 3 tids = 260 skid_limit = 360 max_amsdus = 3 Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ath10k-ct firmware update
Wave-1: * March 19, 2020: Fix problem where power-save was not enabled when going off-channel to scan. The problem was a boolean logic inversion in the chmgr code, a regression I introduced a long time ago. * March 19, 2020: When scanning only on current working channel, do not bother with disable/enable powersave. This should make an on-channel scan less obtrusive than it was previously. * March 23, 2020: Fix channel-mgr use-after-free problem that caused crashes in some cases. The crash was exacerbated by recent power-save changes. * March 23, 2020: Fix station-mode power-save related crash: backported the fix from 10.2 QCA firmware. * March 23, 2020: Attempt to better clean up power-save objects and state, especially in station mode. Wave-2: No changes since last time I posted. If someone can get these patched into OpenWrt I'd appreciate it. 988x 2f0bf766e400a4c5726e77b128eb8c141ebaa778526fe2c7c5083f3b17659dbf firmware-2-ct-full-community-22.bin.lede.017 5e4285d5c6eee159a25ca14c6ce26022c32380bd7bafaedfc0c5de1510119007 firmware-2-ct-full-htt-mgt-community-22.bin.lede.017 /home/greearb/candela_html/downloads 9887 4fa30e0e1972ca3b06225a731df0f93a1b73ac67fea5bf54bb55dea3bbc0da6a firmware-2-ct-full-community-22.bin.lede.017 dc681b6b1e45956e7c2e418ab05eee5c943d13e775209196d9bd931ff6493935 firmware-2-ct-full-htt-mgt-community-22.bin.lede.017 /home/greearb/candela_html/downloads 9980 289ea845d4bbae6f36b3af2a13a5eaa07097f52d10f7b7306cfc9e2dd394f889 firmware-5-ct-full-community-12.bin-lede.017 adedcd3d379a910bc3a5257d75f8970e11319f4cd9c1b34440d35821602a8b9c firmware-5-ct-full-htt-mgt-community-12.bin-lede.017 /home/greearb/candela_html/downloads 9984 8175be5b3946bddc042be018ff7713e67b41b59374ef4cdd183185b59274c91a firmware-5-ct-full-community-12.bin-lede.017 eb8b894cfe0d1aaa87f130bb7fd1815ef07b951c14df8a2ceaeb780df8f640e0 firmware-5-ct-full-htt-mgt-community-12.bin-lede.017 /home/greearb/candela_html/downloads 4019 29e9f662c4cd287213877abfbb90fbabb5e32dd3710d3ade82aa94a0921972ae firmware-5-ct-full-community-12.bin-lede.017 559c911f23856b1d3d864ce714d1bef7262bf6638e93e057ecf8d5dba48ca1e6 firmware-5-ct-full-htt-mgt-community-12.bin-lede.017 /home/greearb/candela_html/downloads 9888 b295880a8b08ec2680d85daaf5f20232a0e73d9cc579bf3efd7ffae24ea340d7 firmware-5-ct-full-community-12.bin-lede.017 26fe7c00df10e93373a0f9f105e85d02bb8b1cdd629183ce22a5147138336aec firmware-5-ct-full-htt-mgt-community-12.bin-lede.017 Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Updated ath10k-ct driver
I just pushed a fix for wave-1 firmware. This bug was exacerbated by a firmware fix that made power-save work better. Firmware update email coming next... commit 3d173a471d3e583f2885ce68190c4387424cecc5 (HEAD -> master, origin/master) Author: Ben Greear Date: Wed Mar 25 13:57:07 2020 -0700 ath10k-ct: Fix 5-sec flushing hang on wave-1 ath10k-ct firmware. The driver cannot wait for a singe vdev to flush, so we just don't wait for the flush. This fixes 5-second hangs when bringing down stations, especially when power-save is enabled on a station. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] New ath10k-ct driver, supports vlans on 10.1 firmware.
Sorry for the stale subject, this one is NOT actually about vlans. On 3/17/20 10:01 AM, Ben Greear wrote: commit 8df0a7f80a8bb2c49d3a16fe70f9a619d7bedd5a (HEAD -> master, origin/master) Author: Ben Greear Date: Tue Mar 17 09:58:25 2020 -0700 ath10k-ct: Pull in recent 5.4 stable, etc Includes better tx-override support for wave-1 Wave-1 can now disable periodic calibration (I think, not sure it works properly, but only useful for testing anyway most likely). Signed-off-by: Ben Greear If someone can pull this into OpenWRT and test I'd appreciate it. New firmware images coming shortly... Thanks, Ben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New ath10k-ct firmware available
Wave-1 changes, some debugging code for a crash someone reported, plus: * February 28, 2020: Fix custom-tx path when sending in 0x0 for rate-code. Have tries == 0 mean one try but NO-ACK (similar to how wave-2 does it). wave-2: * Fixed some long-ago regressions related to powersave and/or multicast. Maybe fix some additional multicast and/or tx-scheduling bugs. If someone can test and add this into OpenWRT I'd appreciate it. [greearb@ww2 downloads]$ ~/bin/fw_lede.bash 988x 76a371af99aedae45c4ab41f2a012e74efbbe57cba79cc3c8c66cb9f25974a7e firmware-2-ct-full-community-22.bin.lede.016 bbe20d981283bef454ccb80c33f40ef7ff60e33b1445ec8d740a34547bd3148c firmware-2-ct-full-htt-mgt-community-22.bin.lede.016 /home/greearb/candela_html/downloads 9887 beb795edd55698bfc2f32bdf9cda95bc1224eed9661f9cb61adeb64e0ec6b919 firmware-2-ct-full-community-22.bin.lede.016 4fcc630358b01675211556c7d7f3ff2bf9e6a58e06d56c3a633404558a44ece5 firmware-2-ct-full-htt-mgt-community-22.bin.lede.016 /home/greearb/candela_html/downloads 9980 289ea845d4bbae6f36b3af2a13a5eaa07097f52d10f7b7306cfc9e2dd394f889 firmware-5-ct-full-community-12.bin-lede.016 adedcd3d379a910bc3a5257d75f8970e11319f4cd9c1b34440d35821602a8b9c firmware-5-ct-full-htt-mgt-community-12.bin-lede.016 /home/greearb/candela_html/downloads 9984 8175be5b3946bddc042be018ff7713e67b41b59374ef4cdd183185b59274c91a firmware-5-ct-full-community-12.bin-lede.016 eb8b894cfe0d1aaa87f130bb7fd1815ef07b951c14df8a2ceaeb780df8f640e0 firmware-5-ct-full-htt-mgt-community-12.bin-lede.016 /home/greearb/candela_html/downloads 4019 29e9f662c4cd287213877abfbb90fbabb5e32dd3710d3ade82aa94a0921972ae firmware-5-ct-full-community-12.bin-lede.016 559c911f23856b1d3d864ce714d1bef7262bf6638e93e057ecf8d5dba48ca1e6 firmware-5-ct-full-htt-mgt-community-12.bin-lede.016 /home/greearb/candela_html/downloads 9888 b295880a8b08ec2680d85daaf5f20232a0e73d9cc579bf3efd7ffae24ea340d7 firmware-5-ct-full-community-12.bin-lede.016 26fe7c00df10e93373a0f9f105e85d02bb8b1cdd629183ce22a5147138336aec firmware-5-ct-full-htt-mgt-community-12.bin-lede.016 /home/greearb/candela_html/downloads Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New ath10k-ct driver, supports vlans on 10.1 firmware.
commit 8df0a7f80a8bb2c49d3a16fe70f9a619d7bedd5a (HEAD -> master, origin/master) Author: Ben Greear Date: Tue Mar 17 09:58:25 2020 -0700 ath10k-ct: Pull in recent 5.4 stable, etc Includes better tx-override support for wave-1 Wave-1 can now disable periodic calibration (I think, not sure it works properly, but only useful for testing anyway most likely). Signed-off-by: Ben Greear If someone can pull this into OpenWRT and test I'd appreciate it. New firmware images coming shortly... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] New ath10k-ct driver, supports vlans on 10.1 firmware.
On 02/17/2020 07:24 PM, Кирилл Луконин wrote:
Hello, Ben.
Does it mean that AP VLAN mode will use software encryption for every tx frame?
Best regards,
Kirill Lukonin
Hello,
I have not tested it, so not certain. Matthias reported it worked for him in
light
testing.
If you can test this, please do let us know how it works for you.
Thanks,
Ben
вт, 18 февр. 2020 г., 7:34 Ben Greear mailto:gree...@candelatech.com>>:
Thanks to Matthias Larisch for adding support for AP vlans on 10.1 ct
firmware and testing it out.
Upstream commit ID:
bed49a5f6824fcd8757fd27f6b2a4f6ea933bf2f
If someone can pull this into OpenWRT and test I'd appreciate it.
Thanks,
Ben
--
Ben Greear mailto:gree...@candelatech.com>>
Candela Technologies Inc http://www.candelatech.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org <mailto:openwrt-devel@lists.openwrt.org>
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New ath10k-ct driver, supports vlans on 10.1 firmware.
Thanks to Matthias Larisch for adding support for AP vlans on 10.1 ct firmware and testing it out. Upstream commit ID: bed49a5f6824fcd8757fd27f6b2a4f6ea933bf2f If someone can pull this into OpenWRT and test I'd appreciate it. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New ath10k-ct firmware available.
This supports better per-chain noise floor reporting, which in turn allows for better RSSI reporting in the driver. Wave-2 fixes a long-standing rate-ctrl problem when connected to xbox (and probably other devices). Wave-2 has fix for crash likely related to rekeying. Wave-1 has some debugging code added where a user reported a crash. If someone can test and push to upstream OpenWRT I'd appreciate it. 988x a3a760d0d72707feffa496b6d2266bd9195f09806553b36420b60c0f12b8b87e firmware-2-ct-full-community-22.bin.lede.015 3114a54103d2b492fa1ef903769721f59953c829020d62502a1ec411ab4146d5 firmware-2-ct-full-htt-mgt-community-22.bin.lede.015 /home/greearb/candela_html/downloads 9887 71e8b76dfd7c786d2f57bb7df207dcd13a91d3b492cfbd28916f084d0d1bb5e7 firmware-2-ct-full-community-22.bin.lede.015 b085e5d2239727b72bc647a76864431b8ac48438e6a33b1d55edc468f6ff firmware-2-ct-full-htt-mgt-community-22.bin.lede.015 /home/greearb/candela_html/downloads 9980 edebe2f6f169cdd05c81a8a78156fb3426a66f415e7946af2ae4b7310fca5fe3 firmware-5-ct-full-community-12.bin-lede.015 1ef67fb07da9082886e4dd554dfc19256e10b500faf9e4b2a5774d0238130bae firmware-5-ct-full-htt-mgt-community-12.bin-lede.015 /home/greearb/candela_html/downloads 9984 c2f04da3285aad37baef9c37c9905a31927175dd234cd4378fd56c106e5c9379 firmware-5-ct-full-community-12.bin-lede.015 0c9ede1036750d68885e6481fa84f3cb72192b8440b47719344f7327a030f05d firmware-5-ct-full-htt-mgt-community-12.bin-lede.015 /home/greearb/candela_html/downloads 4019 1acbb7e7a6300091715a3dfe1b248c7833734961de52cc3465c1ed231a4d84f1 firmware-5-ct-full-community-12.bin-lede.015 1065e4d3e55da84ec9e69268a4c5dba55ea33827c48a7c14bb8f0c167eb11b4c firmware-5-ct-full-htt-mgt-community-12.bin-lede.015 /home/greearb/candela_html/downloads 9888 559ebd16872a8b43443c51bb4b7d021e5b75e65893d333d9393f3f6012f4ac79 firmware-5-ct-full-community-12.bin-lede.015 4feaf5e7c4c1745f499ba8c3125db41675800ebedaea455c418c117805c5b372 firmware-5-ct-full-htt-mgt-community-12.bin-lede.015 /home/greearb/candela_html/downloads Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New ath10k-ct driver available.
Please see below for commit. New firmware message will follow shortly. If someone can test and push to openwrt I'd appreciate it. commit 3e3d0adb3cc6c6cf56a05ff661796948f09c5aa8 (HEAD -> master, origin/master) Author: Ben Greear Date: Wed Jan 29 08:14:56 2020 -0800 ath10k-ct: Support better RSSI measurements. When used with recent firmware, these changes allow the driver to query per-chain noise-floor from the radio to better calculate the per-chain RSSI. The per-chain RSSI is then summed to provide the 'combined RSSI'. This gives better per-chain RSSI as well as combined RSSI, especially when running with more than 20Mhz bandwidths. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New ath10k-ct wave-2 firmware available
No changes to wave-1, but I make a version .014 copy anyway to keep the makefile in sync. Wave-2 has a fix to make setting txpower work better. Before setting the power was ignored at least some of the time (it also appeared to work mostly, so I guess it was being correctly set in other ways). 988x 19db86003509dedb8ace339c183813ca637d65af24d00666411d1590efe33e13 firmware-2-ct-full-community-22.bin.lede.014 454e67dab545e720369a07be2fee16de008c76db4ab3119e7760bf9f7504c066 firmware-2-ct-full-htt-mgt-community-22.bin.lede.014 /home/greearb/candela_html/downloads 9887 b3c738328427e124701a5735d65cde0f60e4172ae5bc23b00e5b16df7995dbd4 firmware-2-ct-full-community-22.bin.lede.014 4432ccee23133bbaa4a5552e50a1e7e889b257362603e05530e751b67c29b7b5 firmware-2-ct-full-htt-mgt-community-22.bin.lede.014 /home/greearb/candela_html/downloads 9980 9a908f743604a468b651a5f73c49e6b0ba11a05c677b9726fbf041b849d88b25 firmware-5-ct-full-community-12.bin-lede.014 800dd0816702aaca75f3eb5436c2ea724a6c24833838cd54399b9286b4d4fbe8 firmware-5-ct-full-htt-mgt-community-12.bin-lede.014 /home/greearb/candela_html/downloads 9984 a8b12dba478e8c9d4a215f82324382c7554a900e83c31775f8511af84e59fef7 firmware-5-ct-full-community-12.bin-lede.014 d185651b5d3d1f0082720bc6c2bbe43b2a00cdb6333403fac9336a720b1d93ae firmware-5-ct-full-htt-mgt-community-12.bin-lede.014 /home/greearb/candela_html/downloads 4019 4c2e48835219f420b18dc58e31d1387dae0da70d8170c3fc5e7bce39c06cf355 firmware-5-ct-full-community-12.bin-lede.014 743da4d537d094a7839bd8e1f792e4cb8b517101f66777c84fd84585f0b85e64 firmware-5-ct-full-htt-mgt-community-12.bin-lede.014 /home/greearb/candela_html/downloads 9888 5809c8a6b3bd81cbc829b5e90af3c0a3300488fe194524a90e260448158016b6 firmware-5-ct-full-community-12.bin-lede.014 a284943c203ff66ec2e865f20ae2d2aa049b450801d7205b53c9163862228f15 firmware-5-ct-full-htt-mgt-community-12.bin-lede.014 /home/greearb/candela_html/downloads Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices
On 12/16/2019 03:26 AM, Alberto Bursi wrote: On 15/12/19 14:09, Christian Lamparter wrote: But it seems that Ben had a change of heart in this regard. I don't know the details or why, But it makes sense because it would enable his company to save some money for the systems his company sells: <https://www.candelatech.com/lf_systems.php> so there is some value in supporting these devices, especially if someone else does all the work for it. These are wifi/network testing equipment, not network devices. Also I don't see the value in "saving some money" by using a bit less RAM when the cheaper system is sold for 3k, and most stuff is above 10k. You could use standard whitebox x86 stuff at that price point. The low-ram thing is for people using OpenWRT on low-powered AP boards. We don't need it for our test equipment. Hopefully someone can test Paul Fertser's patches, and if they work well, then can be applied to OpenWRT. Maybe later we can conditionally compile it directly into ath10k-ct instead of having the extra patch in OpenWRT. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices
On 12/15/2019 05:09 AM, Christian Lamparter wrote: On Sunday, 15 December 2019 13:01:14 CET Paul Fertser wrote: Thank you for the answer Christian, On Sun, Dec 15, 2019 at 12:00:48PM +0100, Christian Lamparter wrote: I think for this to have any chance of moving forward you'll need to pressure your ODMs and if that doesn't work: Go with a different WIFI chip vendor that supports low memory devices, or add more RAM. From what I can tell, Qualcomm nowadays gets what they want "for free" and for the past four-five years, they certainly didn't feel pressured to add "low memory" support to ath10k. FWIW, OpenWrt's ath10k vendor is CT now, not QCA, so it's not much relevant what do ODMs and (whatever is left from) QCA say, I guess. Well, not sure what you are trying to say here. But I think Ben is free to do what he wants as well. For example see the: "ath10k: add LED and GPIO controlling support for various chipsets" patch that OpenWrt has been carrying because neither upstream (linux-wireless) nor CT wants to integrate it. <https://github.com/openwrt/openwrt/blob/master/package/kernel/ath10k-ct/patches/201-ath10k-4.16_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch> The situation with the "low memory" support wasn't much better. Because from what I remember, there was a discussion about this very topic between Ben an Hauke in the past (and you can see how it played out, since you wouldn't have posted this series if it was integrated back then). But it seems that Ben had a change of heart in this regard. I don't know the details or why, But it makes sense because it would enable his company to save some money for the systems his company sells: <https://www.candelatech.com/lf_systems.php> so there is some value in supporting these devices, especially if someone else does all the work for it. My goal is to have stable and fully featured ath10k that works well for higher powered systems by default (our test rigs are typically powerful x86 with gigs of RAM running Fedora or similar). OpenWRT is all about adding patches on top of upstream projects for specific platforms, so that would easily work with ath10k-ct too. And, if someone wants to write a patch that either modifies ath10k-ct for OpenWRT to work better on certain systems, then by all means, go ahead. This should be just as easy as doing the same thing for upstream ath10k. If someone writes a patch that conditionally compiles for OpenWRT and/or allows OpenWRT to configure smaller memory usage, then I will apply that to my ath10k-ct driver (with caveat that defaults for non openwrt systems needs to remain as is). Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices
On 12/11/19 11:16 AM, Paul Fertser wrote: Hey Ben, On Wed, Dec 11, 2019 at 10:06:26AM -0800, Ben Greear wrote: On 12/11/19 6:44 AM, Paul Fertser wrote: According to many bugreports [0][1][2] the default ath10k-ct kernel ... And also if you want to just have the makefile pass a -DBUILD_ATH10K_SMALL or something like that and #ifdef code in the ath10k-ct driver, then I'd apply that patch to ath10k-ct so that you don't need the patches. I am offering my patch to the OpenWrt maintainers as kind of a stop-gap measure to get ath10k-ct working for the release (or in any way they think is appropriate). Another approach they can choose is to select the upstream ath10k for those devices. Otherwise some previously supported boards will require manual intervention to get WiFi working after an upgrade. Regarding your fwcfg idea, I am not sure it will work as it seems the PCI initialisation is happening before fwcfg is parsed and applied. Adding a Kconfig option is another possibility. But what do you think about an additional module parameter, wouldn't it be the cleanest solution in the long run? If fwcfg will not work, and maybe it just will not due to the reasons you suggest, then I'm fine with adding a module parameter to ath10k-ct. You may want to conditionally compile the default value of that module parameter so that on the small platforms the user does not actually have to set the module param if they want the default (small) values? Thanks, Ben BTW, according to the git logs the patches were initially added by Christian Lamparter, so I hope he can clarify the situation a bit. Probably there were some performance tests executed back than to measure the impact. -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices
/dev/null +++ b/package/kernel/ath10k-ct/patches-smallbuffers/960-0011-ath10k-limit-pci-buffer-size.patch @@ -0,0 +1,76 @@ +--- a/ath10k-4.19/pci.c b/ath10k-4.19/pci.c +@@ -131,7 +131,7 @@ static struct ce_attr host_ce_config_wla + .flags = CE_ATTR_FLAGS, + .src_nentries = 0, + .src_sz_max = 2048, +- .dest_nentries = 512, ++ .dest_nentries = 128, + .recv_cb = ath10k_pci_htt_htc_rx_cb, + }, + +@@ -140,7 +140,7 @@ static struct ce_attr host_ce_config_wla + .flags = CE_ATTR_FLAGS, + .src_nentries = 0, + .src_sz_max = 2048, +- .dest_nentries = 128, ++ .dest_nentries = 64, + .recv_cb = ath10k_pci_htc_rx_cb, + }, + +@@ -167,7 +167,7 @@ static struct ce_attr host_ce_config_wla + .flags = CE_ATTR_FLAGS, + .src_nentries = 0, + .src_sz_max = 512, +- .dest_nentries = 512, ++ .dest_nentries = 128, + .recv_cb = ath10k_pci_htt_rx_cb, + }, + +@@ -192,7 +192,7 @@ static struct ce_attr host_ce_config_wla + .flags = CE_ATTR_FLAGS, + .src_nentries = 0, + .src_sz_max = 2048, +- .dest_nentries = 128, ++ .dest_nentries = 96, + .recv_cb = ath10k_pci_pktlog_rx_cb, + }, + +--- a/ath10k-5.2/pci.c b/ath10k-5.2/pci.c +@@ -131,7 +131,7 @@ static struct ce_attr host_ce_config_wla + .flags = CE_ATTR_FLAGS, + .src_nentries = 0, + .src_sz_max = 2048, +- .dest_nentries = 512, ++ .dest_nentries = 128, + .recv_cb = ath10k_pci_htt_htc_rx_cb, + }, + +@@ -140,7 +140,7 @@ static struct ce_attr host_ce_config_wla + .flags = CE_ATTR_FLAGS, + .src_nentries = 0, + .src_sz_max = 2048, +- .dest_nentries = 128, ++ .dest_nentries = 64, + .recv_cb = ath10k_pci_htc_rx_cb, + }, + +@@ -167,7 +167,7 @@ static struct ce_attr host_ce_config_wla + .flags = CE_ATTR_FLAGS, + .src_nentries = 0, + .src_sz_max = 512, +- .dest_nentries = 512, ++ .dest_nentries = 128, + .recv_cb = ath10k_pci_htt_rx_cb, + }, + +@@ -192,7 +192,7 @@ static struct ce_attr host_ce_config_wla + .flags = CE_ATTR_FLAGS, + .src_nentries = 0, + .src_sz_max = 2048, +- .dest_nentries = 128, ++ .dest_nentries = 96, + .recv_cb = ath10k_pci_pktlog_rx_cb, + }, + -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New ath10k-ct firmware available
Please see new file names and checksums below: 988x 19db86003509dedb8ace339c183813ca637d65af24d00666411d1590efe33e13 firmware-2-ct-full-community-22.bin.lede.013 454e67dab545e720369a07be2fee16de008c76db4ab3119e7760bf9f7504c066 firmware-2-ct-full-htt-mgt-community-22.bin.lede.013 /home/greearb/candela_html/downloads 9887 b3c738328427e124701a5735d65cde0f60e4172ae5bc23b00e5b16df7995dbd4 firmware-2-ct-full-community-22.bin.lede.013 4432ccee23133bbaa4a5552e50a1e7e889b257362603e05530e751b67c29b7b5 firmware-2-ct-full-htt-mgt-community-22.bin.lede.013 /home/greearb/candela_html/downloads 9980 6fa74a3fc87cba97dbc4a7213b760f8d997cd9c5f11900d47d387b23764cf20a firmware-5-ct-full-community-12.bin-lede.013 68e92820c51270eba4f68b24654c4a9408902b2600762b70204f4cb5419bb714 firmware-5-ct-full-htt-mgt-community-12.bin-lede.013 /home/greearb/candela_html/downloads 9984 08aeb883bd2d9258e8f1907cca8a0d2eda1c559a66e228dadffd6798f6877c7d firmware-5-ct-full-community-12.bin-lede.013 38ed59a2b3c66c10926706a21ae2d3aeaf83e589f19345a8f48d6520522e4fde firmware-5-ct-full-htt-mgt-community-12.bin-lede.013 /home/greearb/candela_html/downloads 4019 feca75fe89af9a3e998047f85ff3428676f4d574b770d51773bb419d0dd98e5a firmware-5-ct-full-community-12.bin-lede.013 6a4977689343f43edd934823512f031fd1a026e872004343b9952077f9607cb0 firmware-5-ct-full-htt-mgt-community-12.bin-lede.013 /home/greearb/candela_html/downloads 9888 d6a59c17bfbec1abc8498762d9f00b2449cab352feb8bef8b621771168376dbf firmware-5-ct-full-community-12.bin-lede.013 fe242c0d56494975d7a1aeb6969d90cc21cb133fba99040d4da7a25fdb90d92c firmware-5-ct-full-htt-mgt-community-12.bin-lede.013 /home/greearb/candela_html/downloads The release notes since last time for wave-1: * November 29, 2019: Fix IBSS merge issue, related to TSF id leakage bug in firmware code. Thanks for Ahmed Zaki @ Mage-Networks for helping to diagnose and test. The release notes since last time for wave-2: * December 6, 2019: Fix 160Mhz problem caused by logic that did not take into account the fact that 160Mhz has only 1/2 of the NSS of lower bandwidths in the rate table. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k memory leak on 19.07 branch and mikrotik RB952Ui-5ac2nD?
On 12/6/19 9:44 AM, Joe Ayers wrote: Possibly the same symptoms don't exist on 128MB RAM devices. Like there is some if condition, which is doing some nasty things on 64M devices? I admit, that I don't have ath10k-ct source code under my pillow, but it doesn't make much sense to me. Comparable results between above and my 64MB device. However, if the sleep time is extended the consumption is more Ok, I'll let it run overnight with 120s sleep in between. I suspect this is not the intended behavior. No its not and it's even strange, that I'm not seeing it here if it should happen in the "default setup". Maybe its because: 1. You're using custom image (I'm using official prebuilt images) 2. You're not providing all the steps needed to reproduce the issue 3. I've way different hardware Every detail could make huge difference. -- ynezz On the device I am testing, it is both (2GHz) ath9k and (5GHz) ath10k. These look to be related patches to this issue: 960-0010-ath10k-limit-htt-rx-ring-size.patch 960-0011-ath10k-limit-pci-buffer-size.patch In the v19.07.0-rc2 build for the rb-nor-flash-16M-ac ar71xx image, these patches are applied to backports-4.19.85-1, but don't seem to be applied to ath10k-ct-2019-09-09-5e8cd86f.Should ath10k-ct have these and other patches?The device's installed packages do include ath10k-ct (from downloads.openwrt.org installed image). I think that if you need the patches for upstream ath10k, then you should also apply the patches to ath10k-ct. Platforms with more memory probably do not need or benefit from those patches. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New ath10k-ct firmware available
Please see new file names and checksums below: 988x 3b2c584f7070c3e286ce27a370cc181d70b45f9cdaa462fb4f44c6c20d2ee8c1 firmware-2-ct-full-community-22.bin.lede.012 a7042b2c90de82b21e87f243411b6fb12142bb4fb28266ea92cdf3101557b6de firmware-2-ct-full-htt-mgt-community-22.bin.lede.012 /home/greearb/candela_html/downloads 9887 c3f891b2cd4e225e1c635a328af3dce94481b096432020e445f71144dda749d5 firmware-2-ct-full-community-22.bin.lede.012 f5e9825279d590a2362f44aef4ced345376cccd65d9b826c131d4dbcef4e689c firmware-2-ct-full-htt-mgt-community-22.bin.lede.012 /home/greearb/candela_html/downloads 9980 4b90fa91dcab68350fe695b3c918cb9a4fb09c2b419519b8b84b71da4cfde5e8 firmware-5-ct-full-community-12.bin-lede.012 6dd40233fe99d99c69781d6514cf9ba7862b3f66c647f7921ca8be6100799986 firmware-5-ct-full-htt-mgt-community-12.bin-lede.012 /home/greearb/candela_html/downloads 9984 2551f5c0bfa6c1b1222bd9452e14f60b8e29c8c0fe85de8af95393f31d544ea3 firmware-5-ct-full-community-12.bin-lede.012 90f947257e1f42496b22cbdd29be99fbc8ea8700045b4ed2380acc980b4c247b firmware-5-ct-full-htt-mgt-community-12.bin-lede.012 /home/greearb/candela_html/downloads 4019 cd85fc9df8b3652f7b12c2ab745b2a9691dca5ca38f8d65a02003e938ad8b570 firmware-5-ct-full-community-12.bin-lede.012 67a923cda6ec3936ef23ec6c30c80dfc9bfd2cee73a142d2e308e8f035b8ed3a firmware-5-ct-full-htt-mgt-community-12.bin-lede.012 /home/greearb/candela_html/downloads 9888 4bdb71b50c68f1a07c88d21f84a6c054fe1b8cb5bacd089a6b9f0a56448535d3 firmware-5-ct-full-community-12.bin-lede.012 e1f0242a91af58ec5628bb4f7c015f6c8dba55f92e2813f8f0b97c86ec496d2d firmware-5-ct-full-htt-mgt-community-12.bin-lede.012 /home/greearb/candela_html/downloads The release notes since last time for wave-1: * October 5, 2019: Fix too-short msg caused by invalid use of PayloadLen in receive path. This appears to resolve the issue of getting (and ignoring) too-short commands when we detect loss of CE interrupts and go into polling mode. * October 12, 2019: Fix regression in IBSS mode that caused SWBA overrun issues. Related to regression added during the ct-station logic, specifically TSF allocation. Thanks for Ahmed Zaki @ Mage-Networks for helping to diagnose and test. * October 15, 2019: Only send beacon tx completion events if we can detect CT driver is being used (based on CT_STATS_OK flag being set). This should help CT firmware work better on stock driver. The release notes since last time for wave-2: * October 15, 2019: Only send beacon tx completion events if we can detect CT driver is being used (based on ATH10k_USE_TXCOMPL_TXRATE2 | ATH10k_USE_TXCOMPL_TXRATE1 flags being set). This should help CT firmware work better on stock driver. * October 31, 2019: Compile out peer-ratecode-list-event. ath10k driver ignores the event. * November 1, 2019: Fix rate-ctrl related crash when nss and other things were changed while station stays associated. See bug: https://github.com/greearb/ath10k-ct/issues/96 Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Any interest in a 'ct' iperf3?
On 10/31/19 5:50 AM, Petr Štetiar wrote: Ben Greear [2019-10-29 06:23:52]: The original SO_BINDTODEVICE patches were offered upstream and there is no interest. It seems like there's finally some interest[1] and you do a good job over there. Someone asked me to create a different branch, and asked for some other feature, but no serious code review or comments that make me think anyone is seriously looking at the patches. Thanks, Ben My recent changes would need rebasing to clean them up before upstreaming, and I am not going to spend any serious time on that since I'd still have to run my own tree to get the SO_BINDTODEVICE patches and anything else not accepted upstream. I think, that there's no need for iperf3-ct package. In general, I would like to move iperf3 to package feeds, where I think it belongs[2]. I assume, that nobody is going to object against any additional upstreamable patches on top of iperf3 package if they provide widely useful features/improvements and fixes. It should be enough to just put relevant link to the upstream PR/patchwork/mailinglist to get them included. 1. https://github.com/esnet/iperf/pull/817 2. http://lists.infradead.org/pipermail/openwrt-devel/2019-August/018399.html -- ynezz -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Any interest in a 'ct' iperf3?
On 10/28/2019 11:14 PM, Petr Štetiar wrote: Ben Greear [2019-10-28 14:42:32]: Hi Ben, found and fixed a bunch of issues apart from lack of time, do you've any other good reason to not upstream those changes? :-) The original SO_BINDTODEVICE patches were offered upstream and there is no interest. My recent changes would need rebasing to clean them up before upstreaming, and I am not going to spend any serious time on that since I'd still have to run my own tree to get the SO_BINDTODEVICE patches and anything else not accepted upstream. Thanks, Ben and of course possibly added some new bugs. As always, those could be probably spotted by another pair of eyes during upstream review process. Is there any interest in adding an iperf3-ct option to openwrt? I can't speak for the rest, but from my point of view we don't need extra package for that purpose. * Support SO_BINDTODEVICE. * Make sockets non-blocking to fix various ways the client and server can hang. * Server will recover from client doing bad things or dying unexpectedly. * Fix socket leaks * Allow compiling for win32 using mingw cross-compiler. * Report summary stats in all cases on both client and server. Those changes looks like a good upstream material. -- ynezz -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Any interest in a 'ct' iperf3?
We added iperf3 support to our network testing tool, so we could more easily use generic third-party systems as remote traffic endpoints. While doing this, I ended up getting iperf3 to compile for and run stable on windows, found and fixed a bunch of issues, and of course possibly added some new bugs. Is there any interest in adding an iperf3-ct option to openwrt? If so, I'll cook up a patch. Here is my change notes for what I did: iperf 3.7-CT: Changes from upstream iperf3 * Support SO_BINDTODEVICE. * Make sockets non-blocking to fix various ways the client and server can hang. * Server will recover from client doing bad things or dying unexpectedly. * Fix socket leaks * Report summary stats in all cases on both client and server. * Allow compiling for win32 using mingw cross-compiler. * Add lots of optionally-enabled debugging to help understand what is going on when adding new features or debugging problems. Source code can be found here: https://github.com/greearb/iperf Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] hotplug: Allow renaming wireless phy devices.
On 10/27/19 6:35 AM, John Crispin wrote:
On 17/12/2018 17:48, gree...@candelatech.com wrote:
From: Ben Greear
uci set wireless.@wifi-device[0].phyname=wiphy0
Then reboot and/or re-plug that device, and this will
name the phy wiphy0 instead of phy0, phy1, etc.
This can help keep phy names consistent through driver reloads
which may make the system easier to configure properly or to
make different systems have the same naming (where wiphy0 is always
the 2.4Ghz radio, for instance).
Signed-off-by: Ben Greear
---
.../kernel/mac80211/files/mac80211.hotplug | 32 +++
1 file changed, 32 insertions(+)
diff --git a/package/kernel/mac80211/files/mac80211.hotplug
b/package/kernel/mac80211/files/mac80211.hotplug
index b865552661..a394e3195e 100644
--- a/package/kernel/mac80211/files/mac80211.hotplug
+++ b/package/kernel/mac80211/files/mac80211.hotplug
@@ -3,3 +3,35 @@
[ "${ACTION}" = "add" ] && {
/sbin/wifi config
}
+
+
+OPATH=${DEVPATH##/devices/platform/}
+OPATH=${OPATH%%/ieee*}
+
+# For USB, OPATH looks like this at this point in this script:
+# soc/soc:usb30@0/1100.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1:1.0
+# But, the uci path has a platform/ prefix on that:
+# platform/soc/soc:usb30@0/1100.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1:1.0
+OPATH_USB="platform/$OPATH";
+
+# 10 radios is enough for anyone!
+#echo "fix-wifi-mac, OPATH: $OPATH" >> /tmp/foo.txt
Hi Ben,
can you please drop all the debug code from the patch and resend
John
It will be a while before I get a chance to rebase my tree
and do any useful testing, and I would rather not send in a patch
that has not had any testing.
So, I can resend later, or maybe someone else will have time to make the
tweaks and test against current upsteram code.
Thanks,
Ben
+for i in `seq 0 9`;
+ do
+ BUS=`uci get wireless.@wifi-device[$i].path`
+ #echo "fix-wifi-mac, BUS[$i]: $BUS" >> /tmp/foo.txt
+ if [ "$BUS " == "$OPATH " ] || [ "$BUS " == "$OPATH_USB " ]
+ then
+ PHYNAME=${DEVPATH##*ieee80211/}
+ NPHYNAME=`uci get wireless.@wifi-device[$i].phyname`
+ #echo "fix-wifi-mac, PHYNAME[$i]: $PHYNAME NPHYNAME: $NPHYNAME" >>
/tmp/foo.txt;
+ if [ "$NPHYNAME " != " " ]
+ then
+ if [ "$PHYNAME " != "$NPHYNAME " ]
+ then
+ #echo "fix-wifi-mac, renaming..." >> /tmp/foo.txt;
+ iw $PHYNAME set name $NPHYNAME
+ fi
+ fi
+ fi
+done
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] QCA9994 outdoor 13km link
On 9/25/19 8:14 AM, supp...@maxnet.al wrote:
This is long distance, 5km with 4 dishes on each side. They are all vertical
and all chains have signal range -60 to -65.
I don't have omni antennas. Is there a problem that i am using dishes?
I have no idea, but at the very least, you should document your setup when
complaining of bad throughput or any other problem. Compare good vs bad
situations to see what
is the difference.
That way someone who has actually tried this sort of thing might be able to
offer suggestions.
Thanks,
Ben
On Wed, Sep 25, 2019 at 5:11 PM +0200, "Ben Greear" mailto:gree...@candelatech.com>> wrote:
Is this short distance or long?
Please try short distance with omni antenna first to make sure you are not
hitting the delayed-ack issue
or problems with your antenna.
Change your antenna orientation so that they point in different directions.
Thanks,
Ben
On 9/25/19 6:49 AM, supp...@maxnet.al wrote:
> Hello,
>
> Today i managed to connect the station wds at 80MHz channel. Signal is -56 and i have very low datarates. I have attached a photo.
>
> When station was ddwrt and AP openwrt the datarates were 866/433. TX won't do more than VHT-NSS 1 although RX it's not good either because it's a 4 chain
> radio and it should do VHT-NSS4.
>
> Thank you,
> Klevis
>
>
>
>
> On Mon, Sep 23, 2019 at 6:36 PM +0200, "Ben Greear" > wrote: > > Weeks or months or whenever I have time, and maybe sooner if someone > wants to sponsor it. Please understand I, and probably everyone else
working > on OpenWRT, am busy with lots of other projects and community work often > gets
pushed to the back burner. > > Thanks, > Ben > > On 9/23/19 8:18
AM, supp...@maxnet.al wrote: > > Hi Ben, > > > > When do you think you might be able to make those
changes to your driver? > > > > Thanks, > > Klevis. > > >
> > > > > On 2019-09-20 13:00, Ben Greear wrote: > >> On 9/20/19 12:55 PM, Vincent Wiemann wrote: >
>>> Hi Klevis, > >>> > >>> have you tried it with a
short distance? > >>> If you did you should better ask Ben Greear directly. > >> >
>> I asked him to post publicly so that others can help answer and that >
>> my own answers might > >> help someone else. > >> > >> I have some patches that
should enable coverage class settings for > >> wave-2, but I am too busy
> >> with other things right now to port them to my ath10k-ct driver/firmware. > >> > >> Thanks, > >> Ben
> >> > >>> > >>> By the way ath10k gen 2 chipsets
don't work very well with long distance links without a > >>> special
feature which implementation is only available to companies like Ubiquiti and very few
> >>> people who have an own reverse-engineered implementation. > >>> It works on IPQ401X, QCA9886
and QCA9888 based chips only. > >>> > >>> And it is not
possible to set a coverage class for gen 2 devices, yet as far as I know due to missing
> >>> documentation and implementation (correct me if that
information is outdated). > >>> Furthermore a high channel width often results in problems >
>>> due to lower receiver sensibility. > >>> We have better
experiences with lower channel widths and sometimes get more throughput with that. >
>>> > >>> Actually I think this does not explain your connection issues
as 13 km is not that much. > >>> > >>> Regards, > >>> > >>> Vincent Wiemann > >>> > >>> On
20.09.19 18:30, supp...@maxnet.al wrote: > >>>> Hello everyone, >
>>>> > >>>> I am trying to setup a custom made outdoor link with Apu2d2
board devices and QCA9994 cards from compex. After i installed openwrt and ath10k
ct driver, > >>>> kmod ath10k and board-2.bin the device can run a 80MHz
channel in WDS AP. The problem is that it won't run as station or station wds. It
can scan > >>>> the SSIDs but won't connect them. > >>>> > >>>> Any suggestion? > >>>> > >>>> Thank you! > >>>>
Klevis > >>>> > >>> > >>>
___ > >>> openwrt-devel mailing list > >>>
openwrt-devel@lists.openwrt.org > >>>
https://lists.openwrt.org/mailman/listinfo/openwrt-devel > >>> > > > > > -- >
Ben GreearCandela Technologies Inc http://www.candelatech.com > -- Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] QCA9994 outdoor 13km link
Is this short distance or long?
Please try short distance with omni antenna first to make sure you are not
hitting the delayed-ack issue
or problems with your antenna.
Change your antenna orientation so that they point in different directions.
Thanks,
Ben
On 9/25/19 6:49 AM, supp...@maxnet.al wrote:
Hello,
Today i managed to connect the station wds at 80MHz channel. Signal is -56 and
i have very low datarates. I have attached a photo.
When station was ddwrt and AP openwrt the datarates were 866/433. TX won't do more than VHT-NSS 1 although RX it's not good either because it's a 4 chain
radio and it should do VHT-NSS4.
Thank you,
Klevis
On Mon, Sep 23, 2019 at 6:36 PM +0200, "Ben Greear" mailto:gree...@candelatech.com>> wrote:
Weeks or months or whenever I have time, and maybe sooner if someone
wants to sponsor it. Please understand I, and probably everyone else
working
on OpenWRT, am busy with lots of other projects and community work often
gets pushed to the back burner.
Thanks,
Ben
On 9/23/19 8:18 AM, supp...@maxnet.al wrote:
> Hi Ben,
>
> When do you think you might be able to make those changes to your driver?
>
> Thanks,
> Klevis.
>
>
>
> On 2019-09-20 13:00, Ben Greear wrote:
>> On 9/20/19 12:55 PM, Vincent Wiemann wrote:
>>> Hi Klevis,
>>>
>>> have you tried it with a short distance?
>>> If you did you should better ask Ben Greear directly.
>>
>> I asked him to post publicly so that others can help answer and that
>> my own answers might
>> help someone else.
>>
>> I have some patches that should enable coverage class settings for
>> wave-2, but I am too busy
>> with other things right now to port them to my ath10k-ct driver/firmware.
>>
>> Thanks,
>> Ben
>>
>>>
>>> By the way ath10k gen 2 chipsets don't work very well with long
distance links without a
>>> special feature which implementation is only available to companies
like Ubiquiti and very few
>>> people who have an own reverse-engineered implementation.
>>> It works on IPQ401X, QCA9886 and QCA9888 based chips only.
>>>
>>> And it is not possible to set a coverage class for gen 2 devices, yet
as far as I know due to missing
>>> documentation and implementation (correct me if that information is
outdated).
>>> Furthermore a high channel width often results in problems
>>> due to lower receiver sensibility.
>>> We have better experiences with lower channel widths and sometimes get
more throughput with that.
>>>
>>> Actually I think this does not explain your connection issues as 13 km
is not that much.
>>>
>>> Regards,
>>>
>>> Vincent Wiemann
>>>
>>> On 20.09.19 18:30, supp...@maxnet.al wrote:
>>>> Hello everyone,
>>>>
>>>> I am trying to setup a custom made outdoor link with Apu2d2 board devices and QCA9994 cards from compex. After i installed openwrt and ath10k ct driver,
>>>> kmod ath10k and board-2.bin the device can run a 80MHz channel in WDS AP. The problem is that it won't run as station or station wds. It can scan
>>>> the SSIDs but won't connect them.
>>>>
>>>> Any suggestion?
>>>>
>>>> Thank you!
>>>> Klevis
>>>>
>>>
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>>
>
--
Ben GreearCandela Technologies Inc http://www.candelatech.com
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] QCA9994 outdoor 13km link
Weeks or months or whenever I have time, and maybe sooner if someone wants to sponsor it. Please understand I, and probably everyone else working on OpenWRT, am busy with lots of other projects and community work often gets pushed to the back burner. Thanks, Ben On 9/23/19 8:18 AM, supp...@maxnet.al wrote: Hi Ben, When do you think you might be able to make those changes to your driver? Thanks, Klevis. On 2019-09-20 13:00, Ben Greear wrote: On 9/20/19 12:55 PM, Vincent Wiemann wrote: Hi Klevis, have you tried it with a short distance? If you did you should better ask Ben Greear directly. I asked him to post publicly so that others can help answer and that my own answers might help someone else. I have some patches that should enable coverage class settings for wave-2, but I am too busy with other things right now to port them to my ath10k-ct driver/firmware. Thanks, Ben By the way ath10k gen 2 chipsets don't work very well with long distance links without a special feature which implementation is only available to companies like Ubiquiti and very few people who have an own reverse-engineered implementation. It works on IPQ401X, QCA9886 and QCA9888 based chips only. And it is not possible to set a coverage class for gen 2 devices, yet as far as I know due to missing documentation and implementation (correct me if that information is outdated). Furthermore a high channel width often results in problems due to lower receiver sensibility. We have better experiences with lower channel widths and sometimes get more throughput with that. Actually I think this does not explain your connection issues as 13 km is not that much. Regards, Vincent Wiemann On 20.09.19 18:30, supp...@maxnet.al wrote: Hello everyone, I am trying to setup a custom made outdoor link with Apu2d2 board devices and QCA9994 cards from compex. After i installed openwrt and ath10k ct driver, kmod ath10k and board-2.bin the device can run a 80MHz channel in WDS AP. The problem is that it won't run as station or station wds. It can scan the SSIDs but won't connect them. Any suggestion? Thank you! Klevis ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] QCA9994 outdoor 13km link
On 9/20/19 12:55 PM, Vincent Wiemann wrote: Hi Klevis, have you tried it with a short distance? If you did you should better ask Ben Greear directly. I asked him to post publicly so that others can help answer and that my own answers might help someone else. I have some patches that should enable coverage class settings for wave-2, but I am too busy with other things right now to port them to my ath10k-ct driver/firmware. Thanks, Ben By the way ath10k gen 2 chipsets don't work very well with long distance links without a special feature which implementation is only available to companies like Ubiquiti and very few people who have an own reverse-engineered implementation. It works on IPQ401X, QCA9886 and QCA9888 based chips only. And it is not possible to set a coverage class for gen 2 devices, yet as far as I know due to missing documentation and implementation (correct me if that information is outdated). Furthermore a high channel width often results in problems due to lower receiver sensibility. We have better experiences with lower channel widths and sometimes get more throughput with that. Actually I think this does not explain your connection issues as 13 km is not that much. Regards, Vincent Wiemann On 20.09.19 18:30, supp...@maxnet.al wrote: Hello everyone, I am trying to setup a custom made outdoor link with Apu2d2 board devices and QCA9994 cards from compex. After i installed openwrt and ath10k ct driver, kmod ath10k and board-2.bin the device can run a 80MHz channel in WDS AP. The problem is that it won't run as station or station wds. It can scan the SSIDs but won't connect them. Any suggestion? Thank you! Klevis ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] New ath10k-ct firmware available.
Yes, I think it is probably dynamic VLANs. And it should work with any wave
2 ath10k chipset including 9984.
I'm interested to know if it works or not.
Thanks,
Ben
On 9/11/19 1:30 PM, Carlito Nueno wrote:
Hi Ben,
I was wondering if AP-VLAN is same as dynamic VLAN.
If so, will this feature work with ar71xx board - QCA9984
I can test it and let you know if I see any issues.
Thank you making ath10-ct!
On Mon, Sep 9, 2019 at 12:55 PM Ben Greear mailto:gree...@candelatech.com>> wrote:
This enables a feature flag in the wave-2 firmware wmi-services indicating
it can send
software-encrypted raw frames. This should in turn allow the AP-VLAN
feature to work.
For those that know how to use AP-VLANs, please try this wave-2 FW and the
latest ath10k-ct
driver(commit: 5e8cd86f90dac966d12df6ece84ac41458d0e95f) and let me know
if it works as expected
or not.
988x
5872fe046d90d844a6d3e232e47a6865bac551d7043b2874147c077e356b35d8
firmware-2-ct-full-community-22.bin.lede.011
4568c3895a101ad28363491ea935f56a48bddea4c1be1889a6ba8d151902062a
firmware-2-ct-full-htt-mgt-community-22.bin.lede.011
/home/greearb/candela_html/downloads
9887
2c64ab22159d04cd345b8caffdd76ac95c0409729121a7a4095c5192f46013b2
firmware-2-ct-full-community-22.bin.lede.011
c806b8894faf3bbb11004f77196c6d711b9a6c187b1512d84e05fa98a5aba2ab
firmware-2-ct-full-htt-mgt-community-22.bin.lede.011
/home/greearb/candela_html/downloads
9980
4ed106dbe8431945afc6a995765f245f574713095b567df35f1397bba5f6fa2e
firmware-5-ct-full-community-12.bin-lede.011
7434c84c501e00a24cbca338569ba150a9ec137ee2b9fa52d13484794300924c
firmware-5-ct-full-htt-mgt-community-12.bin-lede.011
/home/greearb/candela_html/downloads
9984
9af817e65dc9f195517f05ad25f0eca693632ea03b55739a2e0f0fc82e810405
firmware-5-ct-full-community-12.bin-lede.011
11e11663150185e712f70bd29ac41b495bf0ecbfc3334cada8a8c10a42f0
firmware-5-ct-full-htt-mgt-community-12.bin-lede.011
/home/greearb/candela_html/downloads
4019
21a6b5b69e3c1591cb9fe6077971ddadb003cac698f2962d4d8d73bc04038bbf
firmware-5-ct-full-community-12.bin-lede.011
87111717ec5279125d397bea45386707684ee707a91f6c58298818fd02bf567f
firmware-5-ct-full-htt-mgt-community-12.bin-lede.011
/home/greearb/candela_html/downloads
9888
3c9f2e914d2a5eb3a413872239045dfcca105483ba83dd9b293e6b8855fda883
firmware-5-ct-full-community-12.bin-lede.011
dcb1bd826e5e1ef266fd7ee04410b44d4474d59f6eca0cc634e6432aaf326426
firmware-5-ct-full-htt-mgt-community-12.bin-lede.011
/home/greearb/candela_html/downloads
Thanks,
Ben
--
Ben Greear mailto:gree...@candelatech.com>>
Candela Technologies Inc http://www.candelatech.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org <mailto:openwrt-devel@lists.openwrt.org>
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New ath10k-ct firmware available.
This enables a feature flag in the wave-2 firmware wmi-services indicating it can send software-encrypted raw frames. This should in turn allow the AP-VLAN feature to work. For those that know how to use AP-VLANs, please try this wave-2 FW and the latest ath10k-ct driver(commit: 5e8cd86f90dac966d12df6ece84ac41458d0e95f) and let me know if it works as expected or not. 988x 5872fe046d90d844a6d3e232e47a6865bac551d7043b2874147c077e356b35d8 firmware-2-ct-full-community-22.bin.lede.011 4568c3895a101ad28363491ea935f56a48bddea4c1be1889a6ba8d151902062a firmware-2-ct-full-htt-mgt-community-22.bin.lede.011 /home/greearb/candela_html/downloads 9887 2c64ab22159d04cd345b8caffdd76ac95c0409729121a7a4095c5192f46013b2 firmware-2-ct-full-community-22.bin.lede.011 c806b8894faf3bbb11004f77196c6d711b9a6c187b1512d84e05fa98a5aba2ab firmware-2-ct-full-htt-mgt-community-22.bin.lede.011 /home/greearb/candela_html/downloads 9980 4ed106dbe8431945afc6a995765f245f574713095b567df35f1397bba5f6fa2e firmware-5-ct-full-community-12.bin-lede.011 7434c84c501e00a24cbca338569ba150a9ec137ee2b9fa52d13484794300924c firmware-5-ct-full-htt-mgt-community-12.bin-lede.011 /home/greearb/candela_html/downloads 9984 9af817e65dc9f195517f05ad25f0eca693632ea03b55739a2e0f0fc82e810405 firmware-5-ct-full-community-12.bin-lede.011 11e11663150185e712f70bd29ac41b495bf0ecbfc3334cada8a8c10a42f0 firmware-5-ct-full-htt-mgt-community-12.bin-lede.011 /home/greearb/candela_html/downloads 4019 21a6b5b69e3c1591cb9fe6077971ddadb003cac698f2962d4d8d73bc04038bbf firmware-5-ct-full-community-12.bin-lede.011 87111717ec5279125d397bea45386707684ee707a91f6c58298818fd02bf567f firmware-5-ct-full-htt-mgt-community-12.bin-lede.011 /home/greearb/candela_html/downloads 9888 3c9f2e914d2a5eb3a413872239045dfcca105483ba83dd9b293e6b8855fda883 firmware-5-ct-full-community-12.bin-lede.011 dcb1bd826e5e1ef266fd7ee04410b44d4474d59f6eca0cc634e6432aaf326426 firmware-5-ct-full-htt-mgt-community-12.bin-lede.011 /home/greearb/candela_html/downloads Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New ath10k ct driver and firmware available.
The driver commit is: 9e5ab25027e0971fa24ccf93373324c08c4e992d This should fix a problem with 1560 MTU, 160Mhz on DFS channels, some other small issues on < 5.2 kernels, and for 5.2 driver, it pulls in some upstream stable fixes. wave-1 firmware changes since last update: * June 24, 2019: Try allocating low-priority WMI msgs if high-prio are not available. * June 24, 2019: Init rate-ctrl to start at lowest rate instead of in the middle. Hoping this helps DHCP when station connects from a long distance. wave-2: * June 24, 2019 Start rate-ctrl at minimal values to help DHCP work better for far-away peers. * July 24, 2019 Fix old regression that made /a (and probably /b/g) perform poorly, at least on diet-compiled images. * Aug 8, 2019 Improve a/b/g rate-ctrl by damping the PER swings caused by the all-or-nothing logic of transmitting non-block-ack frames one at a time. I would not be surprised if wave-1 could use similar /a/b/g rate ctrl changes that I put into wave-2, I'm curious to hear of how it works for you if you test it. Firmware checksums for updating OpenWRT: 988x 5872fe046d90d844a6d3e232e47a6865bac551d7043b2874147c077e356b35d8 firmware-2-ct-full-community-22.bin.lede.010 4568c3895a101ad28363491ea935f56a48bddea4c1be1889a6ba8d151902062a firmware-2-ct-full-htt-mgt-community-22.bin.lede.010 /home/greearb/candela_html/downloads 9887 2c64ab22159d04cd345b8caffdd76ac95c0409729121a7a4095c5192f46013b2 firmware-2-ct-full-community-22.bin.lede.010 c806b8894faf3bbb11004f77196c6d711b9a6c187b1512d84e05fa98a5aba2ab firmware-2-ct-full-htt-mgt-community-22.bin.lede.010 /home/greearb/candela_html/downloads 9980 b5ccd56807763bccddf661cfc7dc6aab55215961f70f0e7bd42520c2dca30801 firmware-5-ct-full-community-12.bin-lede.010 2cde201ebaa9e996822aeccaf46633bd6e1dd07c61ecba962519f532e5f92509 firmware-5-ct-full-htt-mgt-community-12.bin-lede.010 /home/greearb/candela_html/downloads 9984 d7e360a220d90eadd67f5c9b5adf7b73d9611127e791e931d4f4890a417060d2 firmware-5-ct-full-community-12.bin-lede.010 411cbdf5f52aac701a79ef5e43bfa57b4d8216c78eb83e48f25e8c11e17f71ff firmware-5-ct-full-htt-mgt-community-12.bin-lede.010 /home/greearb/candela_html/downloads 4019 276f6d4048759f99626dd000c1de64322cbed8a63f5aeb94dfea3127732fefc6 firmware-5-ct-full-community-12.bin-lede.010 53d4bdb6a0fd5a88cbcc04cbed41a36c0a601b912af0f3376c661d7a639a4a58 firmware-5-ct-full-htt-mgt-community-12.bin-lede.010 /home/greearb/candela_html/downloads 9888 268c8c3e771522b5e335328d331c20cea30e44b773656df2d613e76ce8777c1e firmware-5-ct-full-community-12.bin-lede.010 bde9bdcb3ecad94b4f6ab679fb2e266c46bb11b2ef279c2458a98a1e8808542d firmware-5-ct-full-htt-mgt-community-12.bin-lede.010 /home/greearb/candela_html/downloads Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 8/9/19 7:14 AM, Koen Vandeputte wrote: On 09.08.19 15:31, Koen Vandeputte wrote: On 09.08.19 14:48, Ben Greear wrote: On 8/6/19 2:26 AM, Koen Vandeputte wrote: Hi Ben, I finally managed to get to some time to properly take a look using a simple setup. Attached all required files to simulate the issue. I compiled the latest OpenWrt master state, (included a full wpa_supplicant and iperf tools) and ran the 2 starts. Attached also logs as seen from both boards simultaneously. basically: - If the boards finally do link after lots of tries, it will have a >200ms latency and max speed of about 3Mbit. - The wpa_sup config file is the most basic RSN enabled config. - I also tried the current Master state with/without all custom pathes, but the result is the same. - wpa_supp also nags about some missing IE's Hw used: - 2x RB-922UAGS containing a on-board ar988x, capable of 30dBm. - 2x standard 5GHz omni antennae - board seperation distance ca 6ft Can you reproduce without encryption enabled? That makes it easier to debug packet sniffs. If you just run ping traffic (or very slow speed tcp/udp), do you still see the issues (like high latency, packet loss, poor on-air encoding rates, etc)? currently rebuilding the setup. will get back on this asap. If I build you a debugging firmware, are you able and willing to reproduce the problem and send me dmesg output as well as on-air packet sniff? Very sure! Preferably, with generated traffic with unique packet sizes (ie, ever increasing, random, or something like that, so I can more easily match up on-air frames with the debugging output. I believe that the beacon issues are probably a symptom of some other failure in the transmit and/or receive path. Thanks, Ben Lets get this fixed! :-) Koen Just tested with encryption disabled: summary: - speed is looking good. (~130Mbit/s) also link speed is 866Mbit (2x2 radio) - iw wlan0 confirms 80MHz channel - Only a single splat seen, no beacon errors - non-htt firmware Please see this bug I opened to track this. It has a firmware debugging image. In case it crashes on FW load, we will have to create and tweak a fwcfg file to decrease number of vdevs, peers, etc since the debugging code uses a lot of instruction space. https://github.com/greearb/ath10k-ct/issues/88 Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 8/6/19 2:26 AM, Koen Vandeputte wrote: Hi Ben, I finally managed to get to some time to properly take a look using a simple setup. Attached all required files to simulate the issue. I compiled the latest OpenWrt master state, (included a full wpa_supplicant and iperf tools) and ran the 2 starts. Attached also logs as seen from both boards simultaneously. basically: - If the boards finally do link after lots of tries, it will have a >200ms latency and max speed of about 3Mbit. - The wpa_sup config file is the most basic RSN enabled config. - I also tried the current Master state with/without all custom pathes, but the result is the same. - wpa_supp also nags about some missing IE's Hw used: - 2x RB-922UAGS containing a on-board ar988x, capable of 30dBm. - 2x standard 5GHz omni antennae - board seperation distance ca 6ft Can you reproduce without encryption enabled? That makes it easier to debug packet sniffs. If you just run ping traffic (or very slow speed tcp/udp), do you still see the issues (like high latency, packet loss, poor on-air encoding rates, etc)? If I build you a debugging firmware, are you able and willing to reproduce the problem and send me dmesg output as well as on-air packet sniff? Preferably, with generated traffic with unique packet sizes (ie, ever increasing, random, or something like that, so I can more easily match up on-air frames with the debugging output. I believe that the beacon issues are probably a symptom of some other failure in the transmit and/or receive path. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k on ipq4019 crashes and hitting WAN_ON macro
On 07/09/2019 11:09 PM, Matej Kupljen wrote: Hi, I have a custom image build from OpenWRT 18.06 and also have updated ath10k driver and ath10k firmware to the latest master version. The device is based on IPQ4019 and the image can be build using "QCA AP-DK04.1-C1" target profile (with some modifications). The device works O.K. and also the wireless is working. However, when there are high number of stations connected to this AP, like over 60, we are experiencing very unstable wireless connection. Looking at the logs we see messages like: ath10k_ahb a80.wifi: failed to set beacon mode for vdev 0: -11 ath10k_ahb a80.wifi: failed to set dtim period for vdev 0: -11 nl80211: wpa_driver_nl80211_event_receive->nl_recvmsgs failed: -5 WARNING: CPU: 3 PID: 9327 at backports-2017-11-01/net/mac80211/sta_info.c:1001 sta_set_sinfo+0x9f4/0xa94 [mac80211] (Unfortunately I do not have the whole log, but I'll try to reproduce this again). It seems like that there was something wrong with the firmware, since we were getting errors that the driver practically cannot set any of the parameters. Those messages were for 5GHZ, on 2.4GHz everything seemed to be normal. We also tried with the ath10k-ct driver and we didn't see any errors there. But there is a huge difference between the drivers, since ath10k-ct only allows up to 32 devices to connect, while ath10k driver allows up to 512 devices. Any idea why? I compile out the swap-to-host-ram logic for peer objects in the ath10k-ct firmware, so it probably cannot handle 512 peers no matter what. But, you can use fwcfg to configure more than 32. We routinely test with 128-ish peers on 9984 and 9880 chips with our firmware, and have not tried to optimize for more peers. https://www.candelatech.com/ath10k-10.4.php#config Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 6/27/19 7:17 AM, Koen Vandeputte wrote:
On 26.06.19 18:39, Ben Greear wrote:
On 6/26/19 9:28 AM, Koen Vandeputte wrote:
On 26.06.19 18:16, Ben Greear wrote:
On 6/26/19 2:02 AM, Koen Vandeputte wrote:
On 25.06.19 15:54, Ben Greear wrote:
On 06/25/2019 02:53 AM, Koen Vandeputte wrote:
On 24.06.19 22:04, Ben Greear wrote:
On 6/24/19 8:32 AM, Koen Vandeputte wrote:
Hi Ben,
Hi All,
So I'm going to give this another try ..
As the IBSS functionality is heavily advertised as a delta to mainline, it
would be very nice to get it working also :)
Testing the latest ath10k-ct driver and firmware seems to be a step back
compared to roughly a month ago.
I'm currently seeing the firmware crashing, which was not the case before:
ath10k-ct + htt-fw:
https://pastebin.com/raw/7Sy9yx6s
Looks like firmware ran out of some WMI event buffers and crashed instead of
handling
it more gracefully.
Please try the attached (untested) firmware and see if it behaves better.
Hi Ben,
1 step forward here.
I'm not seeing crashes anymore using the test-firmware.
https://pastebin.com/raw/4ZeXu7iw
I've linked up 2 IBSS devices (wave 1, VHT80)
OLSR traffic (UDP) works and packets here are nicely going back & forth.
Simply pinging (ICMP) between the 2 devices does not work.
When sending 100 pings, (64 byte large) sometimes 1 gets through .. but with a
latency of > 500ms
I think if the splat and the beacon spam below could be fixed .. this would be
a major step forward:
[ 30.328423] [ cut here ]
[ 30.333251] WARNING: CPU: 0 PID: 1578 at
/mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563 ath10k_mac_vif_beacon_free+0xc7c/0x115c
[ath10k_core]
[ 30.355636] Modules linked in: mbt ath9k ath9k_common qcserial pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci ath10k_core ath usb_wwan sierra_net
sierra rndis_host qmi_wwan pppox ppp_generic mac80211 iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables huawei_cdc_ncm
ftdi_sio cfg80211 cdc_subset cdc_ncm cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limt
[ 30.427331] nls_utf8 nls_iso8859_1 nls_cp437 authenc ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base
usb_common ptp pps_core mii aead crypto_null cryptomgr crc32c_generic crypto_hash
[ 30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not tainted 4.14.129 #0
Please look in your code and let me know the source around the line in mac.c
(6563) that is splatting.
Also, you might grab the latest ath10k-ct repo, it has a tweak that might fix
the SWBA overrun
messages.
https://github.com/greearb/ath10k-ct
Thanks,
Ben
Hi Ben,
Here is the output based on the latest git HEAD of your ct tree, combined with
the test firmware:
https://pastebin.com/raw/kwC6c18J
Hello,
The splat decode does not match the source code, so I'm not which is correct.
OpenWrt seems to add custom patches to your source.
Please find the complete source in subsequent mail as being build.
I did look in that code, and that is where I saw the mismatch. Please check
your own local system
and see if the splat matches your code? Maybe I made some mistake of course...
You can paste ~20 lines of code around the proper splat line and then I can
find it in my
source...
Thanks,
Ben
Hi Ben,
Just retried again on a slightly older commit (2019-05-08) and the splat points
to another location now.
When looking it up, it again points to the WARN_ON pointed below ..
Checking shows that all calls to ath10k_mac_vif_beacon_free() calls are way
above this line (highest line nr is around line1970)
I currently can't explain where the mismatch comes from ..
Current build below is just the git HEAD of openwrt 19.07 branch, cloned, build
and flashed without any modification.
[ 31.956774] WARNING: CPU: 0 PID: 1725 at
/mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563
ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core]
ret = ath10k_config_ps(ar);
if (ret)
ath10k_warn(ar, "failed to setup ps on vdev %i: %d\n",
arvif->vdev_id, ret);
}
if (changed & BSS_CHANGED_MCAST_RATE &&
---> !WARN_ON(ath10k_mac_vif_chan(arvif->vif, &def))) {
band = def.chan->band;
I think this might not be to serious of a bug, and probably does not cause any
real
trouble.
It is also probably a bug in mac80211 or similar, but not certain about that.
The general set of bugs related to IBSS seem to be inability to transmit frames
sometimes (though it usually works well in my lab, so I have not been able to
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 6/26/19 9:28 AM, Koen Vandeputte wrote: On 26.06.19 18:16, Ben Greear wrote: On 6/26/19 2:02 AM, Koen Vandeputte wrote: On 25.06.19 15:54, Ben Greear wrote: On 06/25/2019 02:53 AM, Koen Vandeputte wrote: On 24.06.19 22:04, Ben Greear wrote: On 6/24/19 8:32 AM, Koen Vandeputte wrote: Hi Ben, Hi All, So I'm going to give this another try .. As the IBSS functionality is heavily advertised as a delta to mainline, it would be very nice to get it working also :) Testing the latest ath10k-ct driver and firmware seems to be a step back compared to roughly a month ago. I'm currently seeing the firmware crashing, which was not the case before: ath10k-ct + htt-fw: https://pastebin.com/raw/7Sy9yx6s Looks like firmware ran out of some WMI event buffers and crashed instead of handling it more gracefully. Please try the attached (untested) firmware and see if it behaves better. Hi Ben, 1 step forward here. I'm not seeing crashes anymore using the test-firmware. https://pastebin.com/raw/4ZeXu7iw I've linked up 2 IBSS devices (wave 1, VHT80) OLSR traffic (UDP) works and packets here are nicely going back & forth. Simply pinging (ICMP) between the 2 devices does not work. When sending 100 pings, (64 byte large) sometimes 1 gets through .. but with a latency of > 500ms I think if the splat and the beacon spam below could be fixed .. this would be a major step forward: [ 30.328423] [ cut here ] [ 30.333251] WARNING: CPU: 0 PID: 1578 at /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563 ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core] [ 30.355636] Modules linked in: mbt ath9k ath9k_common qcserial pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci ath10k_core ath usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic mac80211 iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables huawei_cdc_ncm ftdi_sio cfg80211 cdc_subset cdc_ncm cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limt [ 30.427331] nls_utf8 nls_iso8859_1 nls_cp437 authenc ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common ptp pps_core mii aead crypto_null cryptomgr crc32c_generic crypto_hash [ 30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not tainted 4.14.129 #0 Please look in your code and let me know the source around the line in mac.c (6563) that is splatting. Also, you might grab the latest ath10k-ct repo, it has a tweak that might fix the SWBA overrun messages. https://github.com/greearb/ath10k-ct Thanks, Ben Hi Ben, Here is the output based on the latest git HEAD of your ct tree, combined with the test firmware: https://pastebin.com/raw/kwC6c18J Hello, The splat decode does not match the source code, so I'm not which is correct. OpenWrt seems to add custom patches to your source. Please find the complete source in subsequent mail as being build. I did look in that code, and that is where I saw the mismatch. Please check your own local system and see if the splat matches your code? Maybe I made some mistake of course... You can paste ~20 lines of code around the proper splat line and then I can find it in my source... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 6/26/19 2:02 AM, Koen Vandeputte wrote: On 25.06.19 15:54, Ben Greear wrote: On 06/25/2019 02:53 AM, Koen Vandeputte wrote: On 24.06.19 22:04, Ben Greear wrote: On 6/24/19 8:32 AM, Koen Vandeputte wrote: Hi Ben, Hi All, So I'm going to give this another try .. As the IBSS functionality is heavily advertised as a delta to mainline, it would be very nice to get it working also :) Testing the latest ath10k-ct driver and firmware seems to be a step back compared to roughly a month ago. I'm currently seeing the firmware crashing, which was not the case before: ath10k-ct + htt-fw: https://pastebin.com/raw/7Sy9yx6s Looks like firmware ran out of some WMI event buffers and crashed instead of handling it more gracefully. Please try the attached (untested) firmware and see if it behaves better. Hi Ben, 1 step forward here. I'm not seeing crashes anymore using the test-firmware. https://pastebin.com/raw/4ZeXu7iw I've linked up 2 IBSS devices (wave 1, VHT80) OLSR traffic (UDP) works and packets here are nicely going back & forth. Simply pinging (ICMP) between the 2 devices does not work. When sending 100 pings, (64 byte large) sometimes 1 gets through .. but with a latency of > 500ms I think if the splat and the beacon spam below could be fixed .. this would be a major step forward: [ 30.328423] [ cut here ] [ 30.333251] WARNING: CPU: 0 PID: 1578 at /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563 ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core] [ 30.355636] Modules linked in: mbt ath9k ath9k_common qcserial pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci ath10k_core ath usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic mac80211 iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables huawei_cdc_ncm ftdi_sio cfg80211 cdc_subset cdc_ncm cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limt [ 30.427331] nls_utf8 nls_iso8859_1 nls_cp437 authenc ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common ptp pps_core mii aead crypto_null cryptomgr crc32c_generic crypto_hash [ 30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not tainted 4.14.129 #0 Please look in your code and let me know the source around the line in mac.c (6563) that is splatting. Also, you might grab the latest ath10k-ct repo, it has a tweak that might fix the SWBA overrun messages. https://github.com/greearb/ath10k-ct Thanks, Ben Hi Ben, Here is the output based on the latest git HEAD of your ct tree, combined with the test firmware: https://pastebin.com/raw/kwC6c18J Hello, The splat decode does not match the source code, so I'm not which is correct. [ 32.341077] [ cut here ] [ 32.345898] WARNING: CPU: 0 PID: 1470 at /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-06-13-f0aa8130/ath10k-4.19/mac.c:6581 ath10k_mac_vif_beacon_free+0xc54/0x112c [ath10k_core] (line 6581 is not in the mac_vif_beacon_free method). Also, please enable the firmware DBGLOG logging per instructions here: http://www.candelatech.com/ath10k-bugs.php This is the suggested level to debug at: 0xc032 Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 06/25/2019 02:53 AM, Koen Vandeputte wrote: On 24.06.19 22:04, Ben Greear wrote: On 6/24/19 8:32 AM, Koen Vandeputte wrote: Hi Ben, Hi All, So I'm going to give this another try .. As the IBSS functionality is heavily advertised as a delta to mainline, it would be very nice to get it working also :) Testing the latest ath10k-ct driver and firmware seems to be a step back compared to roughly a month ago. I'm currently seeing the firmware crashing, which was not the case before: ath10k-ct + htt-fw: https://pastebin.com/raw/7Sy9yx6s Looks like firmware ran out of some WMI event buffers and crashed instead of handling it more gracefully. Please try the attached (untested) firmware and see if it behaves better. Hi Ben, 1 step forward here. I'm not seeing crashes anymore using the test-firmware. https://pastebin.com/raw/4ZeXu7iw I've linked up 2 IBSS devices (wave 1, VHT80) OLSR traffic (UDP) works and packets here are nicely going back & forth. Simply pinging (ICMP) between the 2 devices does not work. When sending 100 pings, (64 byte large) sometimes 1 gets through .. but with a latency of > 500ms I think if the splat and the beacon spam below could be fixed .. this would be a major step forward: [ 30.328423] [ cut here ] [ 30.333251] WARNING: CPU: 0 PID: 1578 at /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563 ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core] [ 30.355636] Modules linked in: mbt ath9k ath9k_common qcserial pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci ath10k_core ath usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic mac80211 iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables huawei_cdc_ncm ftdi_sio cfg80211 cdc_subset cdc_ncm cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limt [ 30.427331] nls_utf8 nls_iso8859_1 nls_cp437 authenc ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common ptp pps_core mii aead crypto_null cryptomgr crc32c_generic crypto_hash [ 30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not tainted 4.14.129 #0 Please look in your code and let me know the source around the line in mac.c (6563) that is splatting. Also, you might grab the latest ath10k-ct repo, it has a tweak that might fix the SWBA overrun messages. https://github.com/greearb/ath10k-ct Thanks, Ben [ 30.454906] Stack : 8050 804c0870 80495404 86fc5a24 8606485c 804e7307 [ 30.463402] 804915c8 062a 805437d0 19a3 87d1ed28 0001 86fc59d8 ebb059e8 [ 30.471880] 8054 68e8 0007 [ 30.480373] 0123 f55b2536 0122 8000 87152504 8710ccc4 [ 30.488863] 0009 19a3 87d1ed28 876fd000 802a3964 8054 [ 30.497355] ... [ 30.499839] Call Trace: [ 30.502320] [<8006c7ac>] show_stack+0x58/0x100 [ 30.506838] [<80086de0>] __warn+0xe4/0x118 [ 30.510994] [<80086ea4>] warn_slowpath_null+0x1c/0x28 [ 30.516158] [<8710ccc4>] ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core] [ 30.523505] ---[ end trace 83fd3571e310245a ]--- [ 33.172852] wlan0: Trigger new scan to find an IBSS to join [ 33.237416] wlan0: Trigger new scan to find an IBSS to join [ 33.243317] wlan0: Trigger new scan to find an IBSS to join [ 33.249205] wlan0: Trigger new scan to find an IBSS to join [ 33.305210] wlan0: Trigger new scan to find an IBSS to join [ 34.049614] wlan0: Trigger new scan to find an IBSS to join [ 34.115369] wlan0: Trigger new scan to find an IBSS to join [ 34.189823] wlan0: Selected IBSS BSSID fa:77:78:55:af:7b based on configured SSID [ 34.280540] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.288002] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.295924] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.303406] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.310839] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.318280] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.325714] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.333148] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.340567] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.348003] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon ... ... Thanks for your swift reply so far and the test-firmware. Regards, Koen ath10k-ct + non-htt-fw: https://pastebin.com/raw/bqVqQmXq Mixing upstream ath10k driver with the non-htt C
Re: [OpenWrt-Devel] ath10k-ct crash Archer C7 v2 - OpenWrt r10307-629e6538a1 - k4.19
On 6/24/19 12:34 PM, Kevin 'ldir' Darbyshire-Bryant wrote: On 24 Jun 2019, at 19:51, Ben Greear wrote: On 6/23/19 3:33 AM, Kevin 'ldir' Darbyshire-Bryant wrote: Unfortunately flyspray won’t let me create a task, so filing this here so it doesn’t get lost. Archer C7 v2 - OpenWrt r10307-629e6538a1 - k4.19 Recently seen the following firmware crashes on the device. Seems to be related to my macbook coming out of power save mode. There's been a recent ath10k-ct firmware bump so unclear if this is a wireless firmware bug or a kernel driver bug, or both. Maybe the crashlog holds a clue. Hello, Does this seem to be a regression, or it never worked well, or you just started testing this type of scenario? Thanks, Ben It’s a regression for me at least. Not seen it before. Does it seem to happen often enough to be something you could bisect? Also, please try the firmware I attached to the previous email to Koen. It has debugging for the crash you saw. I have comments in the nearby code from old strange issues seen there, so not sure it is something new or just maybe triggering some old bug. Thanks, Ben Cheers, Kevin -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct crash Archer C7 v2 - OpenWrt r10307-629e6538a1 - k4.19
On 6/23/19 3:33 AM, Kevin 'ldir' Darbyshire-Bryant wrote: Unfortunately flyspray won’t let me create a task, so filing this here so it doesn’t get lost. Archer C7 v2 - OpenWrt r10307-629e6538a1 - k4.19 Recently seen the following firmware crashes on the device. Seems to be related to my macbook coming out of power save mode. There's been a recent ath10k-ct firmware bump so unclear if this is a wireless firmware bug or a kernel driver bug, or both. Maybe the crashlog holds a clue. Hello, Does this seem to be a regression, or it never worked well, or you just started testing this type of scenario? Thanks, Ben [76300.806621] ath10k_pci :00:00.0: firmware crashed! (guid n/a) [76300.812839] ath10k_pci :00:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub : [76300.822239] ath10k_pci :00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0 [76300.834379] ath10k_pci :00:00.0: firmware ver 10.1-ct-8x-__fH-022-8f2afb9e api 2 features wmi-10.x,mfp,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT crc32 98d412c4 [76300.863764] ath10k_pci :00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 [76300.871195] ath10k_pci :00:00.0: htt-ver 2.2 wmi-op 2 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1 [76300.882843] ath10k_pci :00:00.0: firmware register dump: [76300.888598] ath10k_pci :00:00.0: [00]: 0x4100016C 0x 0x009963E5 0x [76300.896637] ath10k_pci :00:00.0: [04]: 0x 0x00060324 0x 0x [76300.904670] ath10k_pci :00:00.0: [08]: 0x 0x 0x 0x [76300.912706] ath10k_pci :00:00.0: [12]: 0x0005 0x 0x 0x [76300.920750] ath10k_pci :00:00.0: [16]: 0x009B8BAB 0x0094085D 0x 0x009963E5 [76300.928793] ath10k_pci :00:00.0: [20]: 0x809430B8 0x00401A40 0x0001 0x0002 [76300.936837] ath10k_pci :00:00.0: [24]: 0x80940975 0x00401A60 0x001F 0x00403BEC [76300.944869] ath10k_pci :00:00.0: [28]: 0x409406B9 0x00401A80 0x001F 0x000F [76300.952905] ath10k_pci :00:00.0: [32]: 0x 0x00401AA0 0x00050024 0x0403 [76300.960953] ath10k_pci :00:00.0: [36]: 0x 0x 0x 0x [76300.968991] ath10k_pci :00:00.0: [40]: 0x 0x 0x 0x [76300.977034] ath10k_pci :00:00.0: [44]: 0x 0x 0x 0x [76300.985066] ath10k_pci :00:00.0: [48]: 0x 0x 0x 0x [76300.993103] ath10k_pci :00:00.0: [52]: 0x 0x 0x 0x [76301.001146] ath10k_pci :00:00.0: [56]: 0x 0x 0x 0x [76301.009186] ath10k_pci :00:00.0: Copy Engine register dump: [76301.015196] ath10k_pci :00:00.0: [00]: 0x00057400 14 14 3 3 [76301.021745] ath10k_pci :00:00.0: [01]: 0x00057800 20 20 54 55 [76301.028291] ath10k_pci :00:00.0: [02]: 0x00057c00 21 21 84 85 [76301.034826] ath10k_pci :00:00.0: [03]: 0x00058000 28 28 30 28 [76301.041378] ath10k_pci :00:00.0: [04]: 0x00058400 5087 5087 25 241 [76301.048100] ath10k_pci :00:00.0: [05]: 0x00058800 6 6 101 102 [76301.054636] ath10k_pci :00:00.0: [06]: 0x00058c00 22 22 22 22 [76301.061186] ath10k_pci :00:00.0: [07]: 0x00059000 0 0 0 0 [76301.069742] ath10k_pci :00:00.0: debug log header, dbuf: 0x412708 dropped: 0 [76301.078358] ath10k_pci :00:00.0: [0] next: 0x412720 buf: 0x41056c sz: 1500 len: 52 count: 2 free: 0 [76301.088905] ath10k_pci :00:00.0: ath10k_pci ATH10K_DBG_BUFFER: [76301.095175] ath10k: []: 184AA804 0600FC13 1091 0808 184AA804 0100FC17 [76301.104362] ath10k: [0008]: 30194000 6C010041 [76301.68] ath10k_pci :00:00.0: ATH10K_END [76301.116785] ath10k_pci :00:00.0: [1] next: 0x412708 buf: 0x410b5c sz: 1500 len: 0 count: 0 free: 0 [76301.129238] ath10k_pci :00:00.0: removing peer, cleanup-all, deleting: peer 1e425dff vdev: 0 addr: 8c:85:90:36:ea:10 [76301.140415] ath10k_pci :00:00.0: removing peer, cleanup-all, deleting: peer 29f27609 vdev: 0 addr: 08:e6:89:40:12:7e [76301.151549] ath10k_pci :00:00.0: removing peer, cleanup-all, deleting: peer 7cbbd9a3 vdev: 0 addr: c4:61:8b:23:6d:ca [76301.162681] ath10k_pci :00:00.0: removing peer, cleanup-all, deleting: peer 15825a2b vdev: 0 addr: c8:f6:50:68:97:e5 [76301.173808] ath10k_pci :00:00.0: removing peer, cleanup-all, deleting: peer 8f0f5636 vdev: 0 addr: 14:cc:20:be:89:31 [76301.349424] ieee80211 phy0: Hardware restart was requested [76302.616934] ath10k_pci :00:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256 [76302.634435] ath10k_pci :00:00.0: wmi print 'P 128 V 8 T 410' [76302.640835] ath10k_pci :00:00.0: wm
[OpenWrt-Devel] New ath10k-ct firmware and driver available
Here are recent release notes: wave-1: * May 9, 2019: Tweak rate-ctrl: Ramp PER up faster, down slower. This helps throughput in rate-vs-range test, especially with nss1. * May 20, 2019: Disable adaptive-CCA. I am not sure it helps, and it may make it slower to detect noise that should tell the system to stop transmitting. If someone has means to test this properly, I'd be happy to work with them. wave-2: * May 15, 2019 Fix problem where rate-ctrl sometimes used rix of 0x0. * May 15, 2019 Allow raw-tx of encrypted frame. Requires a patch to the driver to use raw mode when skb has WEP flag enabled AND skb is flagged to not be encrypted. Lightly tested. * May 16, 2019 Fix tx-hang that happened when rate-ctrl chose an OFDM rate for 20Mhz and sent that as AMPDU. To fix, limit to (V)HT rates if peer is (V)HT. It seems that MCS0 (V)HT20 should have as good of a chance of being detected as CCK or OFDM. * June 6, 2019 Disable TX-BFEE, TX-BFER for IBSS connections. I suspect this is part of the tx-hang issue seen with IBSS between two 9984 radios. * June 12, 2019 Fix rx-rate reporting in 'fw_stats' logic. This was at least partly due to regressions I had added earlier when working on some multi-vdev enhancements. * June 12, 2019 Fix case where extd peer-stats were not always populated. The stats gathering code did not handle error conditions well. Driver changes include: * Fixing mfp/pmf for management frames (in htt-mgt mode) * Sven's txpower related fixes * raw tx of encrypted frames works (on wave 2, at least) Here are the new locations and checksums for the firmware images. 988x d4ba8b386be0eda7e1e0ea1653e40a9776c9a5eeb4e7fef656466da30628b17b firmware-2-ct-full-community-22.bin.lede.009 12155e9599194c8274d6a96c603f00723b5f036fe8e4c1518ee64cac529a9b34 firmware-2-ct-full-htt-mgt-community-22.bin.lede.009 /home/greearb/candela_html/downloads 9887 9e1a2b30fc9f680ab1a42335b0091953fa600573a7376b2d67f1b4032f518644 firmware-2-ct-full-community-22.bin.lede.009 a19ea4bad001c1781d064114322502d5a612fb917e02480f971412e090d7f452 firmware-2-ct-full-htt-mgt-community-22.bin.lede.009 /home/greearb/candela_html/downloads 9980 5ad3315297ce3a9cce8706b79eae7783d269b76a56063685100c7e8cd3ff47e5 firmware-5-ct-full-community-12.bin-lede.009 52c5eebde1ef130273353630e7e91e4dfb638a7e9a3a74aaef44cdccb5ce5412 firmware-5-ct-full-htt-mgt-community-12.bin-lede.009 /home/greearb/candela_html/downloads 9984 c54a53821d9b4fb36e69adb53277ad16e126afa692e5e488121c53cc39c7c4ba firmware-5-ct-full-community-12.bin-lede.009 7613d3387dc2d83759759bb14e25312c33f3984a11cd59e66ab2b0470f32abb6 firmware-5-ct-full-htt-mgt-community-12.bin-lede.009 /home/greearb/candela_html/downloads 4019 cec771a2f5f911a77b1f254a113de67cc68edc5d02dc06c7fddbccb448340b55 firmware-5-ct-full-community-12.bin-lede.009 aff872b4e6f4f7eb000518d3ff4056565a076b81a9dd3ce8f382ceeab7f069c3 firmware-5-ct-full-htt-mgt-community-12.bin-lede.009 /home/greearb/candela_html/downloads 9888 c307c9cd44f650be9504b44786245381b0b88a4348fce85c76a6993fdc8e9e13 firmware-5-ct-full-community-12.bin-lede.009 1a419f99d8283042434ed2de86e8aba85b9941ff3c75ab0805d71f4c108e272f firmware-5-ct-full-htt-mgt-community-12.bin-lede.009 /home/greearb/candela_html/downloads ath10k-ct HEAD: commit a045b1ce61fe0908468c019e17a3848f7842c927 (HEAD -> master, origin/master) Author: Ben Greear Date: Thu Jun 13 08:45:12 2019 -0700 ath10k: Improve PMF/MPF mgt frame check And add a driver for 5.2 (beta, not even tested yet) kernel. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New ath10k-ct firmware and driver available
Here are recent release notes: wave-1: * April 2, 2019: Support some get/set API for eeprom rate power tables. Mostly backported from 10.2 * April 2, 2019: Support adaptive-CCA, backported from 10.2 * April 3, 2019: Support adding eeprom configAddr pairs via the set-special API. These configAddrs can be used to change the default register settings for up to 12 registers. * May 3, 2019: Fix tx-power settings for 2x2, 3x3 rates. Original logic I put in back in 2016 set 2x2 and 3x3 lower than the needed to be when using most NICs (very high powered NICs would not have been affected I think, not sure any of those exist though.) This improves throughput for 2x2 and 3x3 devices, especially when the signal is weaker. wave-2: * April 8, 2019: When setting keys, if high bit of high value of key_rsc_counter is set to 0x1, then the lower 48 bits will be used as the PN value. By default, PN is set to 1 each time the key is set. * April 8, 2019: Pack PN into un-used 'excretries' aka 'num_pkt_loss_excess_retry' high 16 bits. This lets us report peer PN, but *only* if driver has previously set a PN when setting key (or set-special cmd is used to enable PN reporting). This is done so that we know the driver is recent enough to deal with the PN stat reporting. * April 16, 2019: Support specifying tx rate on a per-beacon packet. See ath10k_wmi_op_gen_beacon_dma and ath10k_convert_hw_rate_to_rate_info for API details. Driver needs additional work to actually enable this feature currently. * April 30, 2019 Compile out tx-prefetch caching logic. It is full of tricky bugs that cause tx hangs. I fixed at least one, but more remain and I have wasted too much time on this already. * May 8, 2019 Start rate-ctrl at mcs-3 instead of mcs-5. This significantly helps DHCP happen quickly, probably because the initial rate being too high would take a while to ramp down, especially since there are few packets sent by the time DHCP needs to start. This bug was triggered by me decreasing retries of 0x1e (upstream default) to 0x4. But, I think it is better to start with lower initial MCS instead of always having a very high retry count. 988x c2407cbdaaf143c9796e654aed026f0aa70fc93a82dd1244c62e95ede894e829 firmware-2-ct-full-community-22.bin.lede.008 789c4d1c8ac5edeb43d507157944102b564cd6970c365a14b50cab08ffa4e3b5 firmware-2-ct-full-htt-mgt-community-22.bin.lede.008 /home/greearb/candela_html/downloads 9887 07692a63ab9d11a65c17cc896aff89ea33b7af4e0e1e51ae100651291afe3a4d firmware-2-ct-full-community-22.bin.lede.008 ef336462d4a44ab9a0d89e83064124e647a9fb4a8af8be9df5724378611d2e82 firmware-2-ct-full-htt-mgt-community-22.bin.lede.008 /home/greearb/candela_html/downloads 9980 3357d7ba739512619ccd14043338cfe8e148d5d8e99343e3ccf7a2ff0d07d05f firmware-5-ct-full-community-12.bin-lede.008 ce81e1b9b80b30263e9d5010e38fac3f005214fd955dc2cff95e7fe633796212 firmware-5-ct-full-htt-mgt-community-12.bin-lede.008 /home/greearb/candela_html/downloads 9984 e2794ce577ff7942dc5f767a77fa52167f323bc8f50f04570fc5efe92ed761cf firmware-5-ct-full-community-12.bin-lede.008 1f90555963c2e52ac8fc5581b2a0f9c658e3f5205844898bdc48c78d009bb6eb firmware-5-ct-full-htt-mgt-community-12.bin-lede.008 /home/greearb/candela_html/downloads 4019 4e73cf8e24e83df87d6dce2038e350b3f67753ccca37a8c0d1b861818991e6aa firmware-5-ct-full-community-12.bin-lede.008 8f6434856d6f0207bc3f519cf50d2bf45df1bfcbc69b864ed02fcb5cd5ef6f4b firmware-5-ct-full-htt-mgt-community-12.bin-lede.008 /home/greearb/candela_html/downloads 9888 6b627746f88c1bfecb872e72c61d6097192e389592e391630d2661b44f13b10d firmware-5-ct-full-community-12.bin-lede.008 4ef46b2bdd3ddc894f79da2dbf90ee04cb58781f3eb193840bd5fdb8624b447b firmware-5-ct-full-htt-mgt-community-12.bin-lede.008 /home/greearb/candela_html/downloads ath10k-ct HEAD: commit f98b6dc4d27ea2d79a1577285d1d5cb0641b3eb4 (HEAD -> master, origin/master) Author: Ben Greear Date: Wed May 8 13:46:51 2019 -0700 ath10k-ct: Fix printing PN in peer stats. Previous logic was incorrect. Also add set-special API to enable returning PN. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Kernel crash in skb_put caused by ath10k_htt_t2h_msg_handler
On 4/23/19 11:56 PM, Petr Štetiar wrote:
Petr Štetiar [2019-04-05 18:03:11]:
Hi Ben,
Can you use gdb to print out the lines of code around that crash site in
t2h_msg_handler?
[<87622780>] ath10k_htt_t2h_msg_handler+0x27e0/0x31dc [ath10k_core]
(gdb) l *ath10k_htt_t2h_msg_handler+0x27e0
0x227b0 is in ath10k_htt_rx_handle_amsdu
(/ath10k-ct-2019-03-25-2e917efb/ath10k-4.19/htt_rx.c:374).
369
370 /* FIXME: we must report msdu payload since this is
what caller
371 * expects now
372 */
373 skb_put(msdu, offsetof(struct htt_rx_desc,
msdu_payload));
374 skb_pull(msdu, offsetof(struct htt_rx_desc,
msdu_payload));
375
376 /*
377 * Sanity check - confirm the HW is finished filling in
the
378 * rx data.
[<8764901c>] ath10k_ce_rx_update_write_idx+0x9c/0xc4 [ath10k_core]
(gdb) l* ath10k_ce_rx_update_write_idx+0x9c
0x4904c is in ath10k_ce_rx_update_write_idx
(/ath10k-ct-2019-03-25-2e917efb/ath10k-4.19/ce.c:763).
758 if (((cur_write_idx + nentries) & nentries_mask) ==
dest_ring->sw_index)
759 nentries -= 1;
760
761 write_index = CE_RING_IDX_ADD(nentries_mask, write_index,
nentries);
762 ath10k_ce_dest_ring_write_index_set(ar, ctrl_addr, write_index);
763 dest_ring->write_index = write_index;
764 }
765 EXPORT_SYMBOL(ath10k_ce_rx_update_write_idx);
766
767 int ath10k_ce_rx_post_buf(struct ath10k_ce_pipe *pipe, void *ctx,
I can figure out which message caused it I can add debugging and/or protective
code.
Thanks and good luck!
1. http://lists.infradead.org/pipermail/ath10k/2019-April/013138.html
any luck with this bug? While doing some development on my Archer c7v5, I'm
hitting this bug several times a day, so I'm wondering if I could do something
in order to help fixing this. Thanks!
Thanks for the reminder, I had forgotten about this.
Please try this patch and see if you hit the new BUG_ON, let me know the
splat and ath10k_err output if so. Also interesting if you hit the original
bug w/out hitting this new BUG_ON.
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 108da3ceeff6..9ad21f3bb1d5 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -328,6 +328,12 @@ static inline struct sk_buff
*ath10k_htt_rx_netbuf_pop(struct ath10k_htt *htt)
htt->rx_ring.netbufs_ring[idx] = NULL;
ath10k_htt_reset_paddrs_ring(htt, idx);
+ if (!msdu->data) {
+ ath10k_err(ar, "htt-rx-netbuf-pop, msdu: %p has null data. idx: %i
ring-size: %i fill-count: %i",
+ msdu, idx, htt->rx_ring.size_mask,
htt->rx_ring.fill_cnt);
+ BUG_ON(1);
+ }
+
idx++;
idx &= htt->rx_ring.size_mask;
htt->rx_ring.sw_rd_idx.msdu_payld = idx;
Thanks,
Ben
-- ynezz
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct issues - IBSS mode
On 4/15/19 7:07 AM, Koen Vandeputte wrote: On 29.03.19 13:55, Hauke Mehrtens wrote: On 3/29/19 1:43 PM, Ben Greear wrote: On 03/29/2019 02:58 AM, Koen Vandeputte wrote: On 26.03.19 19:39, Ben Greear wrote: On 3/26/19 6:59 AM, Koen Vandeputte wrote: On 26.03.19 14:50, Ben Greear wrote: On 03/26/2019 03:09 AM, Koen Vandeputte wrote: Hi Ben, Following our conversation from yesterday, here is a summary of all issues seen so far: Test setup: - Board: Mikrotik RB922 - Hardware used: on-board QCA9882 (QCA988x), Wave1 2x2 .ac - firmware's tested: both non-HTT and HTT flavours for qca988x Synopsis: - Setting the interface in IBSS mode results in following errors and spamming - Speed is very low (100 kbit/s) upon linking 2 devices in HT20, long GI Hello, Do you see those SWBA overrun messages on both systems, or just one of them? I'll work on fixing the out-of-my-tree compile for 4.20 today, as well as do a quick test on 4.19 to see if I see that error below. Thanks, Ben Hi Ben, A huge amount of then continuously: I updated ath10k-ct (commit-id: be5c21a82b15d28991500a28f7b2b6840356281f) I fixed part of the issue with 4.20 not compiling in openwrt, but the other part appears to be a backports issue, and I did not attempt to get that working. Hi Ben, This is still remaining using 4.20: make[4]: Entering directory '/mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/linux-4.14.109' CC [M] /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-26-be5c21a8/ath10k-4.20/mac.o /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-26-be5c21a8/ath10k-4.20/mac.c: In function 'ath10k_mac_register': /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-26-be5c21a8/ath10k-4.20/mac.c:9772:11: error: 'NL80211_EXT_FEATURE_ACK_SIGNAL_SUPPORT' undeclared (first use in this function); did you mean 'NL80211_EXT_FEATURE_DATA_ACK_SIGNAL_SUPPORT'? NL80211_EXT_FEATURE_ACK_SIGNAL_SUPPORT); ^~ NL80211_EXT_FEATURE_DATA_ACK_SIGNAL_SUPPORT /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-26-be5c21a8/ath10k-4.20/mac.c:9772:11: note: each undeclared identifier is reported only once for each function it appears in I think you will need to go back to 4.19 based driver, or add a hack to #ifdef that code out while compiling in openwrt. I did a brief test with the 4.19 ct driver and it seems to work OK in my test setup. Since it appears openwrt will be stuck on 4.19 for a while, I'll put some more effort into keeping my 4.19 tree up to date. Also, I found a nasty bug with mgt frames in htt-mgt mode yesterday, and uploaded new beta firmware to my web page...will post csums and such to this list later today. Thanks, Ben Hi, I have a more recent mac80211 framework from kernel 5.1-rc2 in my feature branch: https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/mac80211-5.0 I plan to merge this after the next release is branched off. You could try that with ath10k-ct from kernel 4.20. Hauke Hi All, I tested Hauke's idea but it didn't work: Latest mac80211 5.1-rc2 + ath10k-ct (4.19) --> Still the same errors as described initially (tried both CT firmware flavours - see bootlog below for details) Latest mac80211 5.1-rc2 + ath10k-ct (4.20) --> Compile error regarding blockack .. So basically .. IBSS functionality died along the way. I recall I tested it roughly 1.5 years ago and it worked beautifully then. You could try reverting to an older build that worked and then bisect? IBSS at least sort of works in my lab (non-openwrt) setup, for what that is worth. I do see some cases where sometimes I have to restart supplicant to get things working, but once the IBSS link is up, performance is fine. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath10k: reset chip after supported check
Tom Psyborg, check the bottom of this mail, it has the patch in it.
Thanks,
Ben
On 03/25/2019 02:34 PM, Michał Kazior wrote:
On Mon, 25 Mar 2019 at 21:23, Ben Greear wrote:
On 3/25/19 1:08 PM, Michał Kazior wrote:
On Mon, 25 Mar 2019 at 16:55, Ben Greear wrote:
On 3/25/19 5:14 AM, Michał Kazior wrote:
On Sat, 23 Mar 2019 at 08:20, Arend Van Spriel
wrote:
* resending with corrected email address from Kalle
+ Michał
Thanks!
On 3/22/2019 8:25 PM, Christian Lamparter wrote:
> On Friday, March 22, 2019 7:58:40 PM CET Tomislav Požega wrote:
>> When chip reset is done before the chip is checked if supported
>> there will be crash. Previous behaviour caused bootloops on
>> Archer C7 v1 units, this patch allows clean device boot without
>> excluding ath10k driver.
Can you elaborate more a bit? What kind of crashes are you seeing?
What does the bootloop look like? Do you have uart connected to
diagnose?
Didn't C7 v1 have the old QCA9880 hw v1 which isn't really supported
by ath10k? I recall the v1 chip was really buggy and required
hammering registers sometimes to get things working.
The crash is related to the v1 chip. Is there a good way to detect
that this is the chip in question and only apply this work-around
for the problem chip?
I don't know of any good way to do that.
You could consider device-tree but that would be no different from
having a module blacklist in the C7v1 build recipe, or to not build
the module at all. That is unless you actually want to make v1 chip
work with ath10k at which point there's more fun to be had before it
can actually work.
I remember v1, and I have no interest in trying to make it work :)
If we could blacklist certain pci slots in the ath10k driver, I guess
that would work?
I think the goal is to not use the v1 chip, but allow users to add a
v2 NIC to the platform, so driver still needs to load.
That makes sense, but I don't see how blacklisting pci slots would
help someone putting v2 nic into C7v1 mobo? Won't the slot be the same
regardless what nic is put?
The best thing I can come up with is something like this:
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -3629,6 +3629,19 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
goto err_deinit_irq;
}
+ if (hw_rev == ATH10K_HW_QCA988X) {
+ /* v1 can crash the system on chip_reset()
+* so all we can do is keep our fingers
+* crossed v2 never reports 0 without a
+* chip_reset()
+*/
+ if (ath10k_pci_soc_read32(ar, SOC_CHIP_ID_ADDRESS) == 0) {
+ ath10k_err(ar, "qca9880 v1 is chip not supported");
+ ret = -ENOTSUP;
+ goto err_free_irq;
+ }
+ }
+
ret = ath10k_pci_chip_reset(ar);
if (ret) {
ath10k_err(ar, "failed to reset chip: %d\n", ret);
I didn't test it. Someone needs to compile and test and make sure v2
doesn't regress when fw hangs and cold & warm host cpu resets are
mixed in.
Michał
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] mac80211: ath10k: reset chip after supported check
On 4/1/19 2:07 PM, Tom Psyborg wrote: On 01/04/2019, Ben Greear wrote: On 4/1/19 1:32 PM, Tomislav Požega wrote: When chip reset is done before the chip is checked if supported there will be crash. Previous behaviour caused bootloops on Archer C7 v1 units, this patch allows clean device boot without excluding ath10k driver. Did you try the patch that Michal posted that checks the chip version ID and so might be a good and safe fix for all chips? please provide link. i did not get such patch in my inbox I forwarded it separately. If that fixes the problem, then I think it has a decent change of being accepted upstream (as well as into my ath10k-ct repo). If you want to put in a hack like this for a particular platform, maybe make it specific to that one platform so you don't risk instability on a wide range of systems? since other devices use ath10k-ct i decided to switch to ath10k only on this specific platform so it shouldn't be a problem Just because some platforms use ath10k-ct as a default doesn't mean that users don't change the defaults and use the stock driver. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] mac80211: ath10k: reset chip after supported check
On 4/1/19 1:32 PM, Tomislav Požega wrote:
When chip reset is done before the chip is checked if supported
there will be crash. Previous behaviour caused bootloops on
Archer C7 v1 units, this patch allows clean device boot without
excluding ath10k driver.
Did you try the patch that Michal posted that checks the chip version
ID and so might be a good and safe fix for all chips?
If you want to put in a hack like this for a particular platform, maybe
make it specific to that one platform so you don't risk instability on
a wide range of systems?
Thanks,
Ben
Signed-off-by: Tomislav Požega
---
...0-ath10k-reset-chip-after-supported-check.patch | 39
1 files changed, 39 insertions(+), 0 deletions(-)
create mode 100644
package/kernel/mac80211/patches/ath/980-ath10k-reset-chip-after-supported-check.patch
diff --git
a/package/kernel/mac80211/patches/ath/980-ath10k-reset-chip-after-supported-check.patch
b/package/kernel/mac80211/patches/ath/980-ath10k-reset-chip-after-supported-check.patch
new file mode 100644
index 000..81ca5e1
--- /dev/null
+++
b/package/kernel/mac80211/patches/ath/980-ath10k-reset-chip-after-supported-check.patch
@@ -0,0 +1,39 @@
+From: Tomislav Požega
+Date: Fri, 22 Mar 2019 19:06:25 +0100
+Subject: [PATCH] ath10k: reset chip after supported check
+
+When chip reset is done before the chip is checked if supported
+there will be crash. Previous behaviour caused bootloops on
+Archer C7 v1 units, this patch allows clean device boot without
+excluding ath10k driver.
+
+Signed-off-by: Tomislav Požega
+
+--- a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
+@@ -3612,12 +3612,6 @@ static int ath10k_pci_probe(struct pci_d
+ goto err_deinit_irq;
+ }
+
+- ret = ath10k_pci_chip_reset(ar);
+- if (ret) {
+- ath10k_err(ar, "failed to reset chip: %d\n", ret);
+- goto err_free_irq;
+- }
+-
+ chip_id = ath10k_pci_soc_read32(ar, SOC_CHIP_ID_ADDRESS);
+ if (chip_id == 0x) {
+ ath10k_err(ar, "failed to get chip id\n");
+@@ -3630,6 +3624,12 @@ static int ath10k_pci_probe(struct pci_d
+ goto err_free_irq;
+ }
+
++ ret = ath10k_pci_chip_reset(ar);
++ if (ret) {
++ ath10k_err(ar, "failed to reset chip: %d\n", ret);
++ goto err_free_irq;
++ }
++
+ ret = ath10k_core_register(ar, chip_id);
+ if (ret) {
+ ath10k_err(ar, "failed to register driver core: %d\n", ret);
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New ath10k ct firmware is available.
Hello, I fixed a bug that broke sending mgt frames in htt-mgt mode if mgt frame was short (or had very unlucky contents at a certain offset) and previous longer packet was EAPOL or some other high-priority frame types. This bug was in both 10.1 and 10.4 firmware, and I introduced it (or rather, never fixed it) when adding the htt-mgt feature long ago. This resolves some issues with .11r/k/v features, and probably other subtle bugs as well. 10.1: * March 28, 2019: Fix sometimes using bad TID for management frames in htt-mgt mode. (Backported from wave2, looks like bug would be the same though.) 10.4: * March 28, 2019: Fix off-channel scanning while associated in proxy-station mode. * March 29, 2019: Fix sometimes sending mgt frames on wrong tid when using htt-mgt. This bug has been around since I first enabled htt-mgt mode. 988x 56b8faa255d053404981fc0e2ffa8dec1aa6adfffd4e4a2af2b6ac25f131ecce firmware-2-ct-full-community-22.bin.lede.007 f85296afae06548256167a58ecf58f11cc79aba7f96629124dc7b07611f4614f firmware-2-ct-full-htt-mgt-community-22.bin.lede.007 /home/greearb/candela_html/downloads 9887 d42d57ded7de4f8caf4bfd163db0910af7f0e155b11e484dbaa94c341f1e6dec firmware-2-ct-full-community-22.bin.lede.007 2b016a6f59520925ff9996e458c26dde3422e2d142a36e235cca7aad822ad2b6 firmware-2-ct-full-htt-mgt-community-22.bin.lede.007 /home/greearb/candela_html/downloads 9980 3dbf966fdbad9e55936fa62516e2fcca2a5952030132407f80c41d7da819c82c firmware-5-ct-full-community-12.bin-lede.007 c98993f541fbe02e88dfd3d5ed70bbaaad228776da29260348c5b00966682b69 firmware-5-ct-full-htt-mgt-community-12.bin-lede.007 /home/greearb/candela_html/downloads 9984 1bdb2f62fb7f6947db992f0dc48b2864b51c7544ff8672a6c7570ecf2273054c firmware-5-ct-full-community-12.bin-lede.007 ff4c4f734711d4ead8a8ed226c5347073a9ce32b60b91d995f197b6e7809b7c6 firmware-5-ct-full-htt-mgt-community-12.bin-lede.007 /home/greearb/candela_html/downloads 4019 98568845cf82dea679b1f4dee23f3d3eb39755c6bcdaeb89ed188e52e0f42b2d firmware-5-ct-full-community-12.bin-lede.007 b791820962e26ba186d2310c024dd16c5ec44bfbbaf40bfeb77ab30bb297e75f firmware-5-ct-full-htt-mgt-community-12.bin-lede.007 /home/greearb/candela_html/downloads 9888 f96e5d62c9b5d79cad0b0ff702cdd2644c408bcaeb1bd23f340f0425a002c8cd firmware-5-ct-full-community-12.bin-lede.007 1f6d872f29d1635df55737458fc054adc64803638b4ad220ce0ccb13be5c0010 firmware-5-ct-full-htt-mgt-community-12.bin-lede.007 /home/greearb/candela_html/downloads Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct issues - IBSS mode
On 03/29/2019 02:58 AM, Koen Vandeputte wrote: On 26.03.19 19:39, Ben Greear wrote: On 3/26/19 6:59 AM, Koen Vandeputte wrote: On 26.03.19 14:50, Ben Greear wrote: On 03/26/2019 03:09 AM, Koen Vandeputte wrote: Hi Ben, Following our conversation from yesterday, here is a summary of all issues seen so far: Test setup: - Board: Mikrotik RB922 - Hardware used: on-board QCA9882 (QCA988x), Wave1 2x2 .ac - firmware's tested: both non-HTT and HTT flavours for qca988x Synopsis: - Setting the interface in IBSS mode results in following errors and spamming - Speed is very low (100 kbit/s) upon linking 2 devices in HT20, long GI Hello, Do you see those SWBA overrun messages on both systems, or just one of them? I'll work on fixing the out-of-my-tree compile for 4.20 today, as well as do a quick test on 4.19 to see if I see that error below. Thanks, Ben Hi Ben, A huge amount of then continuously: I updated ath10k-ct (commit-id: be5c21a82b15d28991500a28f7b2b6840356281f) I fixed part of the issue with 4.20 not compiling in openwrt, but the other part appears to be a backports issue, and I did not attempt to get that working. Hi Ben, This is still remaining using 4.20: make[4]: Entering directory '/mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/linux-4.14.109' CC [M] /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-26-be5c21a8/ath10k-4.20/mac.o /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-26-be5c21a8/ath10k-4.20/mac.c: In function 'ath10k_mac_register': /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-26-be5c21a8/ath10k-4.20/mac.c:9772:11: error: 'NL80211_EXT_FEATURE_ACK_SIGNAL_SUPPORT' undeclared (first use in this function); did you mean 'NL80211_EXT_FEATURE_DATA_ACK_SIGNAL_SUPPORT'? NL80211_EXT_FEATURE_ACK_SIGNAL_SUPPORT); ^~ NL80211_EXT_FEATURE_DATA_ACK_SIGNAL_SUPPORT /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-26-be5c21a8/ath10k-4.20/mac.c:9772:11: note: each undeclared identifier is reported only once for each function it appears in I think you will need to go back to 4.19 based driver, or add a hack to #ifdef that code out while compiling in openwrt. I did a brief test with the 4.19 ct driver and it seems to work OK in my test setup. Since it appears openwrt will be stuck on 4.19 for a while, I'll put some more effort into keeping my 4.19 tree up to date. Also, I found a nasty bug with mgt frames in htt-mgt mode yesterday, and uploaded new beta firmware to my web page...will post csums and such to this list later today. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct issues - IBSS mode
On 3/26/19 6:59 AM, Koen Vandeputte wrote: On 26.03.19 14:50, Ben Greear wrote: On 03/26/2019 03:09 AM, Koen Vandeputte wrote: Hi Ben, Following our conversation from yesterday, here is a summary of all issues seen so far: Test setup: - Board: Mikrotik RB922 - Hardware used: on-board QCA9882 (QCA988x), Wave1 2x2 .ac - firmware's tested: both non-HTT and HTT flavours for qca988x Synopsis: - Setting the interface in IBSS mode results in following errors and spamming - Speed is very low (100 kbit/s) upon linking 2 devices in HT20, long GI Hello, Do you see those SWBA overrun messages on both systems, or just one of them? I'll work on fixing the out-of-my-tree compile for 4.20 today, as well as do a quick test on 4.19 to see if I see that error below. Thanks, Ben Hi Ben, A huge amount of then continuously: I updated ath10k-ct (commit-id: be5c21a82b15d28991500a28f7b2b6840356281f) I fixed part of the issue with 4.20 not compiling in openwrt, but the other part appears to be a backports issue, and I did not attempt to get that working. I tested my 4.19 kernel and it had a WARN_ON about a chan-def, but I don't think that is what you reported earlier...maybe it is worth trying 4.19 on the commit above. IBSS is flakey in that it seems sometimes I get one-way communication, but I do not see excessive SWBA log spam. It runs fast when it works. I used 'open' auth, possibly things are worse with encryption. I have some tx-path debugging I can enable to try to understand the one-way communication issues, but I don't have time to deal with it right now. From my IRC comments: I tested 9880 IBSS on my 4.20 kernel, first time I associated, I got one way traffic, but after resetting a node, I see bi-dir traffic around 170Mbps one direction, 317Mbps the other (UDP) I see a few SWBA messages, but not many SWBA appears to happen when WMI communication is being slow... You might could enable HTC credit logging and/or WMI logging to better understand why that is happening (credits slow to be returned, very large number of on-going WMI messages, etc) Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct issues - IBSS mode
eneric_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-25-2e917efb/ath10k"-4.20"" NOSTDINC_FLAGS="-I/mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-25-2e917efb -I/mnt/ramdisk/koen/firmware/builds/generic_rb922/staging_dir/target-mips_24kc_musl/usr/include/mac80211-backport/uapi -I/mnt/ramdisk/koen/firmware/builds/generic_rb922/staging_dir/target-mips_24kc_musl/usr/include/mac80211-backport -I/mnt/ramdisk/koen/firmware/builds/generic_rb922/staging_dir/target-mips_24kc_musl/usr/include/mac80211/uapi -I/mnt/ramdisk/koen/firmware/builds/generic_rb922/staging_dir/target-mips_24kc_musl/usr/include/mac80211 -include backport/autoconf.h -include backport/backport.h -DCONFIG_ATH10K_AHB -DSTANDALONE_CT -DCONFIG_MAC80211_DEBUGFS -DCONFIG_ATH10K_DEBUGFS -DCONFIG_ATH10K_DEBUG -DCONFIG_ATH10K_LEDS" modules make[4]: Entering directory '/mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/linux-4.14.108' CC [M] /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-25-2e917efb/ath10k-4.20/mac.o /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-25-2e917efb/ath10k-4.20/mac.c:8987:3: error: 'const struct ieee80211_ops' has no member named 'consume_block_ack' .consume_block_ack = ath10k_mac_consume_block_ack, ^ /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-25-2e917efb/ath10k-4.20/mac.c:8987:24: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .consume_block_ack = ath10k_mac_consume_block_ack, ^~~~ /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-25-2e917efb/ath10k-4.20/mac.c:8987:24: note: (near initialization for 'ath10k_ops.sta_notify') /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-25-2e917efb/ath10k-4.20/mac.c: In function 'ath10k_mac_register': /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-25-2e917efb/ath10k-4.20/mac.c:9769:11: error: 'NL80211_EXT_FEATURE_ACK_SIGNAL_SUPPORT' undeclared (first use in this function); did you mean 'NL80211_EXT_FEATURE_DATA_ACK_SIGNAL_SUPPORT'? NL80211_EXT_FEATURE_ACK_SIGNAL_SUPPORT); ^~ NL80211_EXT_FEATURE_DATA_ACK_SIGNAL_SUPPORT /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-25-2e917efb/ath10k-4.20/mac.c:9769:11: note: each undeclared identifier is reported only once for each function it appears in cc1: some warnings being treated as errors scripts/Makefile.build:326: recipe for target '/mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-03-25-2e917efb/ath10k-4.20/mac.o' failed Kind regards, Koen -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath10k: reset chip after supported check
On 03/25/2019 02:34 PM, Michał Kazior wrote:
On Mon, 25 Mar 2019 at 21:23, Ben Greear wrote:
On 3/25/19 1:08 PM, Michał Kazior wrote:
On Mon, 25 Mar 2019 at 16:55, Ben Greear wrote:
On 3/25/19 5:14 AM, Michał Kazior wrote:
On Sat, 23 Mar 2019 at 08:20, Arend Van Spriel
wrote:
* resending with corrected email address from Kalle
+ Michał
Thanks!
On 3/22/2019 8:25 PM, Christian Lamparter wrote:
> On Friday, March 22, 2019 7:58:40 PM CET Tomislav Požega wrote:
>> When chip reset is done before the chip is checked if supported
>> there will be crash. Previous behaviour caused bootloops on
>> Archer C7 v1 units, this patch allows clean device boot without
>> excluding ath10k driver.
Can you elaborate more a bit? What kind of crashes are you seeing?
What does the bootloop look like? Do you have uart connected to
diagnose?
Didn't C7 v1 have the old QCA9880 hw v1 which isn't really supported
by ath10k? I recall the v1 chip was really buggy and required
hammering registers sometimes to get things working.
The crash is related to the v1 chip. Is there a good way to detect
that this is the chip in question and only apply this work-around
for the problem chip?
I don't know of any good way to do that.
You could consider device-tree but that would be no different from
having a module blacklist in the C7v1 build recipe, or to not build
the module at all. That is unless you actually want to make v1 chip
work with ath10k at which point there's more fun to be had before it
can actually work.
I remember v1, and I have no interest in trying to make it work :)
If we could blacklist certain pci slots in the ath10k driver, I guess
that would work?
I think the goal is to not use the v1 chip, but allow users to add a
v2 NIC to the platform, so driver still needs to load.
That makes sense, but I don't see how blacklisting pci slots would
help someone putting v2 nic into C7v1 mobo? Won't the slot be the same
regardless what nic is put?
I'm not sure about that...maybe let OpenWRT boot by default
assuming the slot is blacklisted, and then disable the blacklist
if known to be a v2 NIC.
If your patch below works, that looks a lot better though.
Hopefully someone with that v1 board can test it.
Thanks,
Ben
The best thing I can come up with is something like this:
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -3629,6 +3629,19 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
goto err_deinit_irq;
}
+ if (hw_rev == ATH10K_HW_QCA988X) {
+ /* v1 can crash the system on chip_reset()
+* so all we can do is keep our fingers
+* crossed v2 never reports 0 without a
+* chip_reset()
+*/
+ if (ath10k_pci_soc_read32(ar, SOC_CHIP_ID_ADDRESS) == 0) {
+ ath10k_err(ar, "qca9880 v1 is chip not supported");
+ ret = -ENOTSUP;
+ goto err_free_irq;
+ }
+ }
+
ret = ath10k_pci_chip_reset(ar);
if (ret) {
ath10k_err(ar, "failed to reset chip: %d\n", ret);
I didn't test it. Someone needs to compile and test and make sure v2
doesn't regress when fw hangs and cold & warm host cpu resets are
mixed in.
Michał
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath10k: reset chip after supported check
On 3/25/19 1:08 PM, Michał Kazior wrote: On Mon, 25 Mar 2019 at 16:55, Ben Greear wrote: On 3/25/19 5:14 AM, Michał Kazior wrote: On Sat, 23 Mar 2019 at 08:20, Arend Van Spriel wrote: * resending with corrected email address from Kalle + Michał Thanks! On 3/22/2019 8:25 PM, Christian Lamparter wrote: > On Friday, March 22, 2019 7:58:40 PM CET Tomislav Požega wrote: >> When chip reset is done before the chip is checked if supported >> there will be crash. Previous behaviour caused bootloops on >> Archer C7 v1 units, this patch allows clean device boot without >> excluding ath10k driver. Can you elaborate more a bit? What kind of crashes are you seeing? What does the bootloop look like? Do you have uart connected to diagnose? Didn't C7 v1 have the old QCA9880 hw v1 which isn't really supported by ath10k? I recall the v1 chip was really buggy and required hammering registers sometimes to get things working. The crash is related to the v1 chip. Is there a good way to detect that this is the chip in question and only apply this work-around for the problem chip? I don't know of any good way to do that. You could consider device-tree but that would be no different from having a module blacklist in the C7v1 build recipe, or to not build the module at all. That is unless you actually want to make v1 chip work with ath10k at which point there's more fun to be had before it can actually work. I remember v1, and I have no interest in trying to make it work :) If we could blacklist certain pci slots in the ath10k driver, I guess that would work? I think the goal is to not use the v1 chip, but allow users to add a v2 NIC to the platform, so driver still needs to load. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New ath10k-ct firmware and driver
I've uploaded new wave-1 and wave-2 firmware, and driver. Could someone please update openwrt to use these? Release notes for wave-1: * March 12, 2019: Add btcoex feature flag for 2.4Ghz only adapters, backported from upstream 10.2 firmware. * March 12, 2019: Support offloading decrypt of PMF blockack frames to the host. This lets us do blockack with PMF and rx-sw-crypt. Normal hwcrypt scenarios would not need this. Release notes for wave-2: * March 12, 2019: Fix crash when tearing down VI TID when pending frames exist. Could reproduce this while doing rmmod when VI traffic was flowing and PMF was enabled but broken. Bad luck could rarely cause it to happen in more normal config too. * March 12, 2019: Support offloading decrypt of PMF blockack frames to the host. This lets us do blockack with PMF and rx-sw-crypt. Normal hwcrypt scenarios would not need this. * March 22, 2019: Re-work problematic patch that attempted to fix transmit on non-QOS tids. It appears buggy in several ways, hopefully improved now. This was introduced last fall. See github bug 78. Firmware names and csums are below: 988x 7e1ecb882cbe2ce7c4841e56dc0c4e09d05fbeb9fc304fab91d668fbed7dbc22 firmware-2-ct-full-community-22.bin.lede.006 f7860efff0ac805507fc00709edd0a3c723d625d2ca72c63eb3080174b971726 firmware-2-ct-full-htt-mgt-community-22.bin.lede.006 /home/greearb/candela_html/downloads 9887 9fe1675591333f2b1cef08b45f03157610646aa4a1b6f65e31c3e8b63315fcd2 firmware-2-ct-full-community-22.bin.lede.006 057022933c9115015af1e0b3f9cd6587161661688cfad0337f24bc548b70fc6e firmware-2-ct-full-htt-mgt-community-22.bin.lede.006 /home/greearb/candela_html/downloads 9980 a79d5159e115c9e5ed2b43c5f8a07c9312744c69cdd878c5b1dc6f27a7de5198 firmware-5-ct-full-community-12.bin-lede.006 b3375e7f86c98ffb572989d9b977a568482364a58aa13524bb318939c2702c7f firmware-5-ct-full-htt-mgt-community-12.bin-lede.006 /home/greearb/candela_html/downloads 9984 d565cd24973d3c9a736fb343fcbc4d5f44f78edf751b648ba42a247cff3d32f6 firmware-5-ct-full-community-12.bin-lede.006 c96ddf7263fee4f98787efcf7f8c968a35ebf578bd8b7a6c5dbc71ec5d4877b7 firmware-5-ct-full-htt-mgt-community-12.bin-lede.006 /home/greearb/candela_html/downloads 4019 5bcba3c527c05ecbef6e42bb15f93ae35f0465264f067fe3060f4256f5b52675 firmware-5-ct-full-community-12.bin-lede.006 9235feac66b36d5929f86e6d6c1dbf5240d1881b5fc3278dea8ee82799356a52 firmware-5-ct-full-htt-mgt-community-12.bin-lede.006 /home/greearb/candela_html/downloads 9888 d0f30e2f43fc618d3d50c261ae889b3698e3641499f358b301b8518e5a665546 firmware-5-ct-full-community-12.bin-lede.006 a8328deec653b6d057f786bf23b4922b6b2e85441ac393ad5c8e5764935d6ca5 firmware-5-ct-full-htt-mgt-community-12.bin-lede.006 /home/greearb/candela_html/downloads In addition, I updated the ath10k-ct driver. It has a pci fix that Tomislav Požega suggested and some support for sw rxcrypt for PMF blockack frames. https://github.com/greearb/ath10k-ct/commits/master Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath10k: reset chip after supported check
On 3/25/19 5:14 AM, Michał Kazior wrote: On Sat, 23 Mar 2019 at 08:20, Arend Van Spriel wrote: * resending with corrected email address from Kalle + Michał Thanks! On 3/22/2019 8:25 PM, Christian Lamparter wrote: > On Friday, March 22, 2019 7:58:40 PM CET Tomislav Požega wrote: >> When chip reset is done before the chip is checked if supported >> there will be crash. Previous behaviour caused bootloops on >> Archer C7 v1 units, this patch allows clean device boot without >> excluding ath10k driver. Can you elaborate more a bit? What kind of crashes are you seeing? What does the bootloop look like? Do you have uart connected to diagnose? Didn't C7 v1 have the old QCA9880 hw v1 which isn't really supported by ath10k? I recall the v1 chip was really buggy and required hammering registers sometimes to get things working. The crash is related to the v1 chip. Is there a good way to detect that this is the chip in question and only apply this work-around for the problem chip? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] About 802.11s mesh on IPQ4019, ath10k-ct and ct-firmware
On 03/10/2019 12:22 AM, Sven Eckelmann wrote: On Sunday, 10 March 2019 05:52:00 CET Xuebing Wang wrote: [...] Are there anyone building 802.11s routers based on tag 18.06.1, 18.06.2 or branch openwrt-18.06? Most(?) companies and community projects just throw the 802.11s forwarding/ routing part away and are running their preferred Layer2/Layer3 mesh protocol (bmxd/6/7, olsrd(2), babeld, batman-adv, ...) over it. But yes, they are still require the meshpoint interface support in ath10k+firmware. A project I am more familiar (and is using 18.06.x) is freifunk-gluon [1]. They just select the ath10k-firmware-* (from kvalo/linux-firmware) for meshpoint setups and ath10k-firmware*-ct for IBSS setups. As far as I know, this will still be possible with OpenWrt 19.xx). And this should also work the same when you want to run 802.11s+HWMP over it. I noticed that in OpenWRT master branch ath10k-ct and ath10k-firmware-qca4019-ct are enabled by default, but they are not enabled in tag 18.06.2. Regarding ath10k vs. ath10k-ct - yes, this is a rather unfortunate situation that we have two different drivers. ath10k-ct is basically ath10k with a ~7000 lines patch on top. You just have to keep in mind that there are some hacks in it which may break standard ath10k/mac80211 features [2]. So you cannot always assume that this can be reported to the ath10k people. And some of the changes in the mac80211 ath10k could be missing in ath10k-ct [3,4]. So you have to figure out yourself which driver better fits your needs. Kind regards, Sven [1] https://github.com/freifunk-gluon/gluon [2] https://github.com/openwrt/openwrt/pull/1862/commits/c1e80f1b6e673912437422e4900facb409e41143#diff-132b371dc289dab58843cae7f9c430f5 So, both of the patches above need to be applied to ath10k-ct 4.19 driver? [3] https://patchwork.ozlabs.org/patch/1051204/ I can apply this one to the 4.19 ath10k-ct driver too, I just am not using 4.19 internally, so...well, no local testing. [4] https://github.com/openwrt/openwrt/pull/1077 It should be pretty easy for someone to write a patch to extend 'fwcfg' feature in ath10k-ct to support this, or just hack in a commit similar to what you did to the stock driver if needed. I'll very likely accept a patch that enables tweaking this based on fwcfg API. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath10k-ct: limit available channels via DT
I've stopped any serious development on my 4.19 kernel, and am mostly using 4.20 now. So, might be worth moving OpenWRT ath10k-ct to use the 4.20 kernel if it is not already doing so? Thanks, Ben On 3/4/19 9:03 AM, David Bauer wrote: This backports upstream commit 34d5629 ath10k: limit available channels via DT ieee80211-freq-limit to the 4.19 ath10k-ct version. Without this patch, disabled channels are still listed as a supported configuration for the radio. The identical patch was also backported by OpenWRT to the non-ct driver. It can be dropped as soon as we switch to an ath10k-ct version based on 4.20 or higher. Signed-off-by: David Bauer --- ...ilable-channels-via-DT-ieee80211-fre.patch | 39 +++ 1 file changed, 39 insertions(+) create mode 100644 package/kernel/ath10k-ct/patches/203-ath10k-Limit-available-channels-via-DT-ieee80211-fre.patch diff --git a/package/kernel/ath10k-ct/patches/203-ath10k-Limit-available-channels-via-DT-ieee80211-fre.patch b/package/kernel/ath10k-ct/patches/203-ath10k-Limit-available-channels-via-DT-ieee80211-fre.patch new file mode 100644 index 00..de4f98549a --- /dev/null +++ b/package/kernel/ath10k-ct/patches/203-ath10k-Limit-available-channels-via-DT-ieee80211-fre.patch @@ -0,0 +1,39 @@ +From bbf0a8af2261bc7ae39b227ff6a1e9f45a008c27 Mon Sep 17 00:00:00 2001 +From: Sven Eckelmann +Date: Mon, 30 Jul 2018 17:31:41 +0200 +Subject: [PATCH] ath10k: Limit available channels via DT ieee80211-freq-limit + +Tri-band devices (1x 2.4GHz + 2x 5GHz) often incorporate special filters in +the RX and TX path. These filtered channel can in theory still be used by +the hardware but the signal strength is reduced so much that it makes no +sense. + +There is already a DT property to limit the available channels but ath10k +has to manually call this functionality to limit the currrently set wiphy +channels further. + +Signed-off-by: Sven Eckelmann + +Forwarded: https://patchwork.kernel.org/patch/10549245/ +--- + drivers/net/wireless/ath/ath10k/mac.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/ath10k-4.19/mac.c b/ath10k-4.19/mac.c +@@ -18,6 +18,7 @@ + + #include "mac.h" + ++#include + #include + #include + #include +@@ -8390,6 +8391,7 @@ int ath10k_mac_register(struct ath10k *a + ar->hw->wiphy->bands[NL80211_BAND_5GHZ] = band; + } + ++ wiphy_read_of_freq_limits(ar->hw->wiphy); + ath10k_mac_setup_ht_vht_cap(ar); + + ar->hw->wiphy->interface_modes = -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New CT wave-2 firmware available.
Hello, I've uploaded a new set of wave-1 and wave-2 ath10k-ct firmware. Recent release notes for wave-1: * Feb 14, 2019: Remove logic that causes assert when swba logic is not initialized. This was seen when trying to bring up 6 VAP vdevs. A similar fix went into wave-2 firmware some time ago. * Feb 27, 2019: Support up to 32 vAP vdevs, fix stack corruption when driver requests too many vAP. * Feb 28, 2019: Support beacon-tx-wmi callback message. This lets driver properly clean up beacon buffers so we don't crash (somethings the entire OS/system) due to DMA errors. Recent release notes for wave-2: * Feb 27. 2019: Support up to 32 AP vdevs. Previous to this, stack would be corrupted if you went past 16 AP vdevs. * Feb 28, 2019: Support beacon-tx-wmi callback message. This lets driver properly clean up beacon buffers. In wave-1, this could crash the entire OS, but I didn't see the same crashes in wave-2, so maybe it is fixed in some other way. Add the feature regardless as it seems proper. Could someone please update OpenWRT to include these. The new ath10k-ct firmware is also updated to support the beacon callback method, but I think someone is already working on adding that to openwrt. Firmware sha-sums are below, you just need to update the firmware makefile to use the new .005 name and new sums. 988x 8108a29440a8fe477fd0c17f600f00850d79c4abfc580cd608f57f0cae878878 firmware-2-ct-full-community-22.bin.lede.005 ecea8d39fde4b63db7d3c01e4417fe6f5aa247ab81bb2518f9179d8945c660c7 firmware-2-ct-full-htt-mgt-community-22.bin.lede.005 /home/greearb/candela_html/downloads 9887 7c3717a4393c6cf1f3872eb210eb9f680e2205b8709ffb827eacc09d4e5b9bbe firmware-2-ct-full-community-22.bin.lede.005 2d813b2235e8e0371bf0fc85b57411b91b9abff3f690e0f564b5a41622fd4a36 firmware-2-ct-full-htt-mgt-community-22.bin.lede.005 /home/greearb/candela_html/downloads 9980 336a55af37b78c8a75c894e84e7a79cc22ad2c982fb836f5d9848a1bc936a493 firmware-5-ct-full-community-12.bin-lede.005 b15d2ad9821a78d30b55695c80f71dc4c8634069dfc2a8d6551854ad2eebed3a firmware-5-ct-full-htt-mgt-community-12.bin-lede.005 /home/greearb/candela_html/downloads 9984 fc05751486e4f4abfa313622c1e43bdd7aabf938f38768433c649368512a7667 firmware-5-ct-full-community-12.bin-lede.005 90aa97c9aae55a878f2509905f4e7e0b1ff73840c2a7c357794b5705144a0edf firmware-5-ct-full-htt-mgt-community-12.bin-lede.005 /home/greearb/candela_html/downloads 4019 c9e704d9b8789394429abb6935e33133c839e1931eea280da03a792943de firmware-5-ct-full-community-12.bin-lede.005 d261db4a4d96c171179a9897acf633e29f77c636a25c5dd07f43f582441e27c2 firmware-5-ct-full-htt-mgt-community-12.bin-lede.005 /home/greearb/candela_html/downloads 9888 f37c9cc959bf8fbda4e7ec648daed8ef056c17cb9d7e7c9ae00956ce9f276490 firmware-5-ct-full-community-12.bin-lede.005 a50a5da7e1bace2ace4cf0208b884f8f0107b68321aa238f6782acb709ae firmware-5-ct-full-htt-mgt-community-12.bin-lede.005 /home/greearb/candela_html/downloads Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 5GHz wifi is broken
recently. I have some API to set the management rates, but not sure it uses the same API as whatever that patch in question is using. Thanks, Ben Cheers, Christian -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] New CT wave-2 firmware available.
Here is a new set of firmware images. This hopefully fixes another rate-ctrl crash, and fixes at least the obvious bug with 4-addr vlans. If you can, please make a patch and submit this upstream to OpenWRT: 9980 e3876b50cbd095f406a5d8eff310148bbef51ddc07d37af51494e35e9a19590d firmware-5-ct-full-community-12.bin-lede.004 59c67a9707fe5c3c632cc19f4b35814abe948dc07274e9aa1095a4e838840388 firmware-5-ct-full-htt-mgt-community-12.bin-lede.004 /home/greearb/candela_html/downloads 9984 96fc12fc46f8520d2f36a081058e214325037313ae48afe245101466e027b6b0 firmware-5-ct-full-community-12.bin-lede.004 7f1211c64b52ab59fc2efb39e7a279847e426de96eeff1e017becea8663f798d firmware-5-ct-full-htt-mgt-community-12.bin-lede.004 /home/greearb/candela_html/downloads 4019 47fc0409b9766cce3718342ea8d272f0153459450bc1833d44a72a1884e81f11 firmware-5-ct-full-community-12.bin-lede.004 fb376ccde84b9a013aafc4ab2db573d0e982ae398aa647042c6f917559293a3a firmware-5-ct-full-htt-mgt-community-12.bin-lede.004 /home/greearb/candela_html/downloads 9888 beb4e2973330c7640e036500f8d2c68fc428a9b2266a077aebb8e8e798eca75c firmware-5-ct-full-community-12.bin-lede.004 15fa57f6c5752877d7c96a05d2301f7eccd01832bc07d15d33246b8c06890d4c firmware-5-ct-full-htt-mgt-community-12.bin-lede.004 Release notes since last time: * Feb 8, 2019: Fix rate-ctrl assert related to bad logic that tried to guess that lower bandwidth probes were automatically successful if higher was. The NSS mismatch that can happen here caused the assert. Just comment out the offending code (per comment from original QCA code). This is bug 69. * Feb 10, 2019: Fix bssid mis-alignment that broke 4-addr vlan mode (bug 67). Original buggy commit was commit 2bf89e70ecd1eaf8d1c70df7d32f99d1e1c47fe3 dev-ds: Better packing of wal_vdev struct. Thanks, Ben On 02/04/2019 03:11 AM, Koen Vandeputte wrote: done & verified. Thanks Ben! Koen On 03.02.19 04:27, Ben Greear wrote: Here are the sha-sums, the 002 version changes to 003. If someone could update openwrt to use them I'd appreciate it. Changelog is at the bottom. I am hoping this resolves the crashes related to rate-ctrl. 9980 6685623e2ee75909f734e45ae9321b9f78b18ed8c585eadef88f951b8aa4b3be firmware-5-ct-full-community-12.bin-lede.003 ea5ccdc88a1371e958b4b5e7657782b1bcc55ac24e11e6fa36a3fce2746be4d6 firmware-5-ct-full-htt-mgt-community-12.bin-lede.003 /home/greearb/candela_html/downloads 9984 0815fffb4757596a5ee41efb8353fb90667e4c26363fbd62a5ccf269e9a55938 firmware-5-ct-full-community-12.bin-lede.003 425b66e51039f1970802940c864ad3d6b743926e310006f6601acb9689144315 firmware-5-ct-full-htt-mgt-community-12.bin-lede.003 /home/greearb/candela_html/downloads 4019 6e9171d012b50053b04572933b619927070b95fd2d8b9274a3e59a374088a09d firmware-5-ct-full-community-12.bin-lede.003 b265428fadda7e3ac33ef977ba1a13788914689110275e57bba7796c583f8480 firmware-5-ct-full-htt-mgt-community-12.bin-lede.003 /home/greearb/candela_html/downloads 9888 fba3ce709cd0e17abec260639034bc99b0157f36c044713201cff2e5b408a6e2 firmware-5-ct-full-community-12.bin-lede.003 943c0ec1967a41f16e27fd1dfebefc9196412d48d4deba204b157bd7b9b90512 firmware-5-ct-full-htt-mgt-community-12.bin-lede.003 * Jan 2, 2019: Rebase patches to make 9980 bisectable. * Jan 2, 2019: Fix scheduling related assert when wal-peer is deleted with pending tx buffers (bug 54, and others) * Jan 7, 2019: Fix specifying retransmits for AMPDU frames. It was previously ignored since it is a 'software' retransmit instead of a hardware retransmit. * Jan 9 2019: Fix potential way to get zero rates selected (and then assert) * Jan 18 2019: pfsched has specific work-around to just return if we find invalid flags AND if we are in an out-of-order situation. Maybe this is last of the pfsched related issues (bug 54 and similar). * Jan 24 2019: The rcSibUpdate method can be called concurrently with IRQ tx-completion callback, and that could potentially allow the tx-completion callback to see invalid state and assert or otherwise mess up the rate-ctrl logic. So, disable IRQs in rcSibUpdate to prevent this. Related to bug 58. * Jan 28 2019: Ensure that cached config is applied to ratectrl objects when fetched from the cache. This should fix part of bug 58. * Jan 28 2019: Ensure that ratectrl objects from cachemgr are always initialized. This fixes another part of bug 58. * Jan 30 2019: Better use of temporary rate-ctrl object. Make sure it is initialized, simplify code path. This finishes up porting forward similar changes I made for wave-1 firmware long ago, and fixes another potential way to hit bug-58 issues. * Jan 30 2019: Cach
[OpenWrt-Devel] New CT wave-2 firmware available.
Here are the sha-sums, the 002 version changes to 003. If someone could update openwrt to use them I'd appreciate it. Changelog is at the bottom. I am hoping this resolves the crashes related to rate-ctrl. 9980 6685623e2ee75909f734e45ae9321b9f78b18ed8c585eadef88f951b8aa4b3be firmware-5-ct-full-community-12.bin-lede.003 ea5ccdc88a1371e958b4b5e7657782b1bcc55ac24e11e6fa36a3fce2746be4d6 firmware-5-ct-full-htt-mgt-community-12.bin-lede.003 /home/greearb/candela_html/downloads 9984 0815fffb4757596a5ee41efb8353fb90667e4c26363fbd62a5ccf269e9a55938 firmware-5-ct-full-community-12.bin-lede.003 425b66e51039f1970802940c864ad3d6b743926e310006f6601acb9689144315 firmware-5-ct-full-htt-mgt-community-12.bin-lede.003 /home/greearb/candela_html/downloads 4019 6e9171d012b50053b04572933b619927070b95fd2d8b9274a3e59a374088a09d firmware-5-ct-full-community-12.bin-lede.003 b265428fadda7e3ac33ef977ba1a13788914689110275e57bba7796c583f8480 firmware-5-ct-full-htt-mgt-community-12.bin-lede.003 /home/greearb/candela_html/downloads 9888 fba3ce709cd0e17abec260639034bc99b0157f36c044713201cff2e5b408a6e2 firmware-5-ct-full-community-12.bin-lede.003 943c0ec1967a41f16e27fd1dfebefc9196412d48d4deba204b157bd7b9b90512 firmware-5-ct-full-htt-mgt-community-12.bin-lede.003 * Jan 2, 2019: Rebase patches to make 9980 bisectable. * Jan 2, 2019: Fix scheduling related assert when wal-peer is deleted with pending tx buffers (bug 54, and others) * Jan 7, 2019: Fix specifying retransmits for AMPDU frames. It was previously ignored since it is a 'software' retransmit instead of a hardware retransmit. * Jan 9 2019: Fix potential way to get zero rates selected (and then assert) * Jan 18 2019: pfsched has specific work-around to just return if we find invalid flags AND if we are in an out-of-order situation. Maybe this is last of the pfsched related issues (bug 54 and similar). * Jan 24 2019: The rcSibUpdate method can be called concurrently with IRQ tx-completion callback, and that could potentially allow the tx-completion callback to see invalid state and assert or otherwise mess up the rate-ctrl logic. So, disable IRQs in rcSibUpdate to prevent this. Related to bug 58. * Jan 28 2019: Ensure that cached config is applied to ratectrl objects when fetched from the cache. This should fix part of bug 58. * Jan 28 2019: Ensure that ratectrl objects from cachemgr are always initialized. This fixes another part of bug 58. * Jan 30 2019: Better use of temporary rate-ctrl object. Make sure it is initialized, simplify code path. This finishes up porting forward similar changes I made for wave-1 firmware long ago, and fixes another potential way to hit bug-58 issues. * Jan 30 2019: Cachemgr did not have a callback for when memory was logically freed. This means that peers could keep stale references to rate-ctrl objects that were in process of being DMA'd into to load a different peer's rate-ctrl state. This was causing the bugcheck logic to fail early and often, and I suspect it might be a root cause of bug 58 as well. The fix is to add a callback and set any 'deleted' memory references to NULL so that we cannot access it accidentally. Thanks to excellent logs and patience from the bug-58 reporter! Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ipq806x: add ath10k calibration data MAC addresses patching
On 12/22/2018 08:30 AM, Christian Lamparter wrote: On Monday, December 17, 2018 11:20:41 PM CET Mathias Kresin wrote: 17/12/2018 19:05, Christian Lamparter: On Saturday, December 15, 2018 9:10:39 PM CET Christian Lamparter wrote: On Wednesday, November 14, 2018 8:39:22 PM CET Ben Greear wrote: On 11/01/2018 03:18 AM, Felix Fietkau wrote: On 2018-10-28 17:39, Christian Lamparter wrote: Ben Greear reported in his patch: |Subject: netgear r7800: Fix mac address of radios. | |Reloading the driver causes the phyX to change, and that |caused the MAC address to change. This is because all ODM/OEMs except QCA bothered to write the correct MAC address for the ath10k wifi into the calibration data. I don't think that's a strong enough reason to further propagate the messy calibration data patching. How about checking the sysfs device path in the hotplug script instead to make sure we're changing the MAC for the right wifi device? Would this mean that the NIC is loaded with one (potentially bogus) MAC, and then hotplug would very soon after set the proper MAC? If so, that is liable to mess up stock ath10k firmware since it will not properly calculate its rx-bssid mask. Let's test it then. Ben, Felix: I've prepared a big, one in all, test patch for the R7800 - that if viable will be split up, upstreamed and merged accordingly. This patch contains: 0. ath10k and ath10k-ct fixes that implement Felix request to "call pdev_set_base_macaddr_cmdid before bringing up the first vif". This is in the "976-ath10k-implement-set-base-macaddr" patch. (Note: the ath10k driver had no support code for this function, nor does it mention what the data the pdev_set_base_macaddr_cmdid takes. I assume it's just 6-bytes for the base MAC.) Ben: Can you please comment if this is all right, or if something needs to be changed? 1. 998-ath10k-retrieve-MAC-address-from-system-firmware-if-.patch This is an upstream patch 2. 950-call-of_get_mac_address-from-device.patch A hack that makes it work. This could be a point of conflict. 3. R7800 dts changes I hope they are correct enough. I don't have the hardware to test it. 4. (userspace code). In the mean time, because this is so much new, experimental stuff. I'll go ahead with the ugly firmware patching for now until this is ready for prime time. Regards, Christian Update: Mathias wrote me yesterday that the ath10k-ct was not working because the ath10k-ct driver now uses the ath10k-4.19 branch. This (and the missing "retrieve MAC address from system firmware if provided" for ath10k-ct) patch has been fixed. The (updated) patches from your staging tree are working fine. Tested on a Homehub 5a (QCA9880) with ath10k and ath10k-ct. Thank you for testing the patches. @Ben: Can you please comment if this is all right with regards to vdev/vif mask, or if something needs to be changed? Because I can't really move forward and look at your "hotplug: Allow renaming wireless phy devices." <https://patchwork.ozlabs.org/patch/1014630/> otherwise. Hello, The set-base-macaddr patch appears to match the 10.4 firmware API. When using CT firmware and driver, you can check the mask by looking at the fw_regs debugfs file: [root@lf0313-6477 ~]# cat /debug/ieee80211/wiphy0/ath10k/fw_regs ath10k Target Register Dump (extras-count: 0) = MAC-FILTER-ADDR-L32 0x MAC-FILTER-ADDR-U16 0x There is no easy way to get the same data out of stock firmware/driver. If you have exactly one vdev active, you would expect the mac-filter to be all FFs as seen above. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New CT firmware images
Hello, New CT FW images are on my site, packaged up for OpenWRT. The wave-1 firmware has one assert removed. The wave-2 has 3 crash fixes that users recently reported. Assuming these stay fixed, that will fix all recent firmware crashes I have seen lately. If someone could update OpenWRT makefile and spot-check this, I'd appreciate it. Thanks, Ben 988x 0080035ce21c83ec452cfb4051fe0ec5a1f6cc99c8887bc9cc0b8be54043be72 firmware-2-ct-full-community-22.bin.lede.002 30dd88647c543486166a72b3ab1b02732048f217518c4d999e94e2cb2d29feaa firmware-2-ct-full-htt-mgt-community-22.bin.lede.002 /home/greearb/candela_html/downloads 9887 ba543d0966d4c3ca53a732613ea8aea14b9d3c388792ba914110f8c8609da4c8 firmware-2-ct-full-community-22.bin.lede.002 7d9e3abbbe12dab13447c96707dcb747c90d0663c7a687352c9bba55e2f4debc firmware-2-ct-full-htt-mgt-community-22.bin.lede.002 /home/greearb/candela_html/downloads 9980 1d4fd0c05368efbaa987e903c1f9c88eb594e23db93e36869f9d5016734996d4 firmware-5-ct-full-community-12.bin-lede.002 435877ebba90224fe3b696c1c459da281230f527ea05c316b7eeceb1a13b5e19 firmware-5-ct-full-htt-mgt-community-12.bin-lede.002 /home/greearb/candela_html/downloads 9984 b9bbb25f5f6753ca46aeaaf93b6b8d84354b38ef292e4ea6255c627edfb00ad7 firmware-5-ct-full-community-12.bin-lede.002 15fd6aa58e5bf96bf7232c739c97598b4573bb514974a8969a8fe21eb3015356 firmware-5-ct-full-htt-mgt-community-12.bin-lede.002 /home/greearb/candela_html/downloads 4019 6ba3a1b883d65546353f4a9246f7e5327922c7c9dfd472c71926737d94cff2db firmware-5-ct-full-community-12.bin-lede.002 fe0d0a32d2f04885ec613b2af0402e8b80783fb165265ded988524e8914af0b2 firmware-5-ct-full-htt-mgt-community-12.bin-lede.002 /home/greearb/candela_html/downloads 9888 46e5bc1e2b3e13f48ef1d81a0927a6053bda1ef18a2acad93da5cc992ffc3e36 firmware-5-ct-full-community-12.bin-lede.002 7a5f3ef4e906549c3e4cd6e6f4e4c68d777206ed7c9f870c0b2d68b59928883e firmware-5-ct-full-htt-mgt-community-12.bin-lede.002 -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] hotplug: Allow renaming phy devices.
On 12/16/2018 11:14 PM, John Crispin wrote: I'd like to review your patch but it hits the ML as an attachment making it impossible. regardless, the subject is misleading, there are lots of phy types and i fail to understand why this is required. John The attachment was due to us enabling DMARC support on our email system to help decrease spam, but we can disable that. I'll resend the patch later today. The phy type in question is wireless phy devices. Is just putting 'wireless' in front of it sufficient to make it more understandable? The patch is helpful to me because if I remove and replace a USB wireless NIC, or reload another wifi driver, then by default it will change name, from /kernel/debug/ieee80211/phy1 to phy2, for instance. My software wants the names to stay the same to make it easier to have a persistent representation of a 'radio'. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] hotplug: Allow renaming phy devices.
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
From: Ben Greear
uci set wireless.@wifi-device[0].phyname=wiphy0
Then reboot and/or re-plug that device, and this will
name the phy wiphy0 instead of phy0, phy1, etc.
Signed-off-by: Ben Greear
---
.../kernel/mac80211/files/mac80211.hotplug| 32 +++
1 file changed, 32 insertions(+)
diff --git a/package/kernel/mac80211/files/mac80211.hotplug
b/package/kernel/mac80211/files/mac80211.hotplug
index b865552661..a394e3195e 100644
--- a/package/kernel/mac80211/files/mac80211.hotplug
+++ b/package/kernel/mac80211/files/mac80211.hotplug
@@ -3,3 +3,35 @@
[ "${ACTION}" = "add" ] && {
/sbin/wifi config
}
+
+
+OPATH=${DEVPATH##/devices/platform/}
+OPATH=${OPATH%%/ieee*}
+
+# For USB, OPATH looks like this at this point in this script:
+# soc/soc:usb30@0/1100.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1:1.0
+# But, the uci path has a platform/ prefix on that:
+# platform/soc/soc:usb30@0/1100.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1:1.0
+OPATH_USB="platform/$OPATH";
+
+# 10 radios is enough for anyone!
+#echo "fix-wifi-mac, OPATH: $OPATH" >> /tmp/foo.txt
+for i in `seq 0 9`;
+ do
+ BUS=`uci get wireless.@wifi-device[$i].path`
+ #echo "fix-wifi-mac, BUS[$i]: $BUS" >> /tmp/foo.txt
+ if [ "$BUS " == "$OPATH " ] || [ "$BUS " == "$OPATH_USB " ]
+ then
+ PHYNAME=${DEVPATH##*ieee80211/}
+ NPHYNAME=`uci get wireless.@wifi-device[$i].phyname`
+ #echo "fix-wifi-mac, PHYNAME[$i]: $PHYNAME NPHYNAME: $NPHYNAME" >>
/tmp/foo.txt;
+ if [ "$NPHYNAME " != " " ]
+ then
+ if [ "$PHYNAME " != "$NPHYNAME " ]
+ then
+ #echo "fix-wifi-mac, renaming..." >> /tmp/foo.txt;
+ iw $PHYNAME set name $NPHYNAME
+ fi
+ fi
+ fi
+done
--
2.19.2
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] rtl8812au: Add out-of-tree driver.
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- From: Ben Greear Use a forked version of the rtl8812au driver that works better with OpenWRT (fix compile bugs, fix phy MAC address, etc) Signed-off-by: Ben Greear --- v2: Fix phy MAC address, clean up Makefile package/kernel/rtl8812AU/Makefile | 53 +++ 1 file changed, 53 insertions(+) create mode 100644 package/kernel/rtl8812AU/Makefile diff --git a/package/kernel/rtl8812AU/Makefile b/package/kernel/rtl8812AU/Makefile new file mode 100644 index 00..8a4006bed3 --- /dev/null +++ b/package/kernel/rtl8812AU/Makefile @@ -0,0 +1,53 @@ +include $(TOPDIR)/rules.mk + +PKG_NAME:=rtl8812au-ct +PKG_RELEASE=1 + +PKG_LICENSE:=GPLv2 +PKG_LICENSE_FILES:= + +PKG_SOURCE_URL:=https://github.com/greearb/rtl8812AU_8821AU_linux.git +PKG_MIRROR_HASH:=7f4b79a828c53b6d8415a1851c1548574f18849cdef625ae1a1bcb94106b5b97 +PKG_SOURCE_PROTO:=git +PKG_SOURCE_DATE:=2018-11-13 +PKG_SOURCE_VERSION:=8593dab5a414cc57301bd9ea4a04a3747a8f8dce + +PKG_MAINTAINER:=Ben Greear +PKG_BUILD_PARALLEL:=1 +#PKG_EXTMOD_SUBDIRS:=rtl8812au-ct + +STAMP_CONFIGURED_DEPENDS := $(STAGING_DIR)/usr/include/mac80211-backport/backport/autoconf.h + +include $(INCLUDE_DIR)/kernel.mk +include $(INCLUDE_DIR)/package.mk + +define KernelPackage/rtl8812au-ct + SUBMENU:=Wireless Drivers + TITLE:=Driver for Realtek 8812 AU devices comfast 912-ac, etc + DEPENDS:=+kmod-mac80211 +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT + FILES:=\ + $(PKG_BUILD_DIR)/rtl8812au.ko + AUTOLOAD:=$(call AutoProbe,rtl8812au) + PROVIDES:=kmod-rtl8812au +endef + +NOSTDINC_FLAGS = \ + -I$(PKG_BUILD_DIR) \ + -I$(PKG_BUILD_DIR)/include \ + -I$(STAGING_DIR)/usr/include/mac80211-backport/uapi \ + -I$(STAGING_DIR)/usr/include/mac80211-backport \ + -I$(STAGING_DIR)/usr/include/mac80211/uapi \ + -I$(STAGING_DIR)/usr/include/mac80211 \ + -include backport/backport.h + +NOSTDINC_FLAGS+=-DCONFIG_IOCTL_CFG80211 -DRTW_USE_CFG80211_STA_EVENT -DBUILD_OPENWRT + +define Build/Compile + +$(MAKE) $(PKG_JOBS) -C "$(LINUX_DIR)" \ + $(KERNEL_MAKE_FLAGS) \ + SUBDIRS="$(PKG_BUILD_DIR)" \ + NOSTDINC_FLAGS="$(NOSTDINC_FLAGS)" \ + modules +endef + +$(eval $(call KernelPackage,rtl8812au-ct)) -- 2.19.2 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Someone want to update ath10k-ct fw?
Hello, I have uploaded new builds for each of the CT firmware I maintain. The wave-1 stuff is in the same place as usual. The wave-2 (firmware-5) is in a new directory structure, with 'b' on the end, so for instance: greearb@ww2 downloads]$ ls -ltr ath10k-9984-10-4b total 1216 drwxrwsr-x. 2 greearb candelatech.com 4096 Oct 12 09:24 ath10k-fw-beta -rw-rw-r--. 1 greearb candelatech.com 618740 Dec 11 12:58 firmware-5-ct-full-community-12.bin-lede.001 -rw-rw-r--. 1 greearb candelatech.com 618436 Dec 11 12:58 firmware-5-ct-full-htt-mgt-community-12.bin-lede.001 The sha256sum and names are below. If someone can update the ath10k-ct firmware makefile in OpenWRT to use these, and do at least some minimal testing, I'd be grateful as I do not have time to do any real testing at this point. Thanks, Ben 88x 7c03642a4f342fc6f9916485c47270893cdc75b4ba2e7fcdd8fbdfa03e8c551b firmware-2-ct-full-community-22.bin.lede.001 afe5ead5058727ed3fc8a0fdc738e705d53295369691e4d1376f85f8a98cefb1 firmware-2-ct-full-htt-mgt-community-22.bin.lede.001 /home/greearb/candela_html/downloads 9887 ba543d0966d4c3ca53a732613ea8aea14b9d3c388792ba914110f8c8609da4c8 firmware-2-ct-full-community-22.bin.lede.001 7d9e3abbbe12dab13447c96707dcb747c90d0663c7a687352c9bba55e2f4debc firmware-2-ct-full-htt-mgt-community-22.bin.lede.001 /home/greearb/candela_html/downloads 9980 9da5863aa92e416c1c4fd66b128f0f14d88840500b3d0b32b9b39cd7985794d9 firmware-5-ct-full-community-12.bin-lede.001 c7a1616e03a05b6456b94230c967da91253a69c000547f0d22b3fbb0f735495b firmware-5-ct-full-htt-mgt-community-12.bin-lede.001 /home/greearb/candela_html/downloads 9984 c68c7e2b1d517fe69e6e94d640630453930c12de2982ed7d2e9132edf476d1b2 firmware-5-ct-full-community-12.bin-lede.001 7d8a733b109d6226c287fd2b3782858e4e5b0b21ba2c29812d5d546d73d76f44 firmware-5-ct-full-htt-mgt-community-12.bin-lede.001 /home/greearb/candela_html/downloads 4019 531f116a68012570110773040e9d9aad97cd036572ea0662c770801f4309ebeb firmware-5-ct-full-community-12.bin-lede.001 79a29994270392ec49cce748bf3c7a62368c6ab4fc0d0102ed21589c866cdf3d firmware-5-ct-full-htt-mgt-community-12.bin-lede.001 /home/greearb/candela_html/downloads 9888 95fbb18d65fbe80ba7fe69f529f8013fc7f6fdcb00795ba5026e0ed2f9c50aa7 firmware-5-ct-full-community-12.bin-lede.001 5fb1d3bc91e72c9be6a3d5f01e32f9ab205b2e1e433011cf867607ee737da5c2 firmware-5-ct-full-htt-mgt-community-12.bin-lede.001 /home/greearb/candela_html/downloads -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath10k-ct: update and use version based on 4.19
On 12/10/18 2:23 PM, Hauke Mehrtens wrote: On 12/10/18 10:46 PM, Ben Greear wrote: On 12/10/18 1:35 PM, Hauke Mehrtens wrote: --- package/kernel/ath10k-ct/Makefile | 10 +- ...h-all-IEs-for-variant-before-falling-back.patch | 8 +- ...-controlling-support-for-various-chipsets.patch | 544 - ...02-ath10k-4.16-use-tpt-trigger-by-default.patch | 39 +- 4 files changed, 580 insertions(+), 21 deletions(-) diff --git a/package/kernel/ath10k-ct/Makefile b/package/kernel/ath10k-ct/Makefile index d47ab8655c..e763135b92 100644 --- a/package/kernel/ath10k-ct/Makefile +++ b/package/kernel/ath10k-ct/Makefile @@ -8,14 +8,14 @@ PKG_LICENSE_FILES:= PKG_SOURCE_URL:=https://github.com/greearb/ath10k-ct.git PKG_SOURCE_PROTO:=git -PKG_SOURCE_DATE:=2018-09-29 -PKG_SOURCE_VERSION:=b9989fbd5d6e3269b3e49ab3ec71b4174a02209e -PKG_MIRROR_HASH:=67bb1c81518aea5880757d521023db25190d9cca21ba67bf1c7e577efd287430 +PKG_SOURCE_DATE:=2018-11-01 +PKG_SOURCE_VERSION:=6c3a6262317f3240013014e79a570693009c0235 +PKG_MIRROR_HASH:=15c832dd49064c9b03c7012b1a50bfb3000227a750f830e832c5fd1f1fe8bfdf Hello, I just pushed the most recent code. Nothing critical, so it can be used later. Thanks I will update, this patch anyway misses a description and a Signed-off-by line. I ran into this problem: ath10k-4.19/wmi.c: In function 'ath10k_dfs_radar_report': ath10k-4.19/wmi.c:4179:4: error: 'struct pulse_event' has no member named 'msg' pe.msg[0] = 0; ^ CC [M] ath10k-4.19/hw.o I haven't yet investigated further what is the problem, but it seams to be related to your last commit. I just pushed a commit that should fix that. I guess the new radar debugfs info will not be in OpenWRT unless someone wants to port the ath patch as well. Probably it is not of general interest anyway. Thanks, Ben Are there any other patches you'd like to see applied to my 4.19 ath10k-ct driver to make inclusion in openwrt easier? Currently this is ok, the list of patches we have on top of your is very small the the changes in this patch, the rest is for older ath10k-ct versions and can probably be dropped anyway. Currently we only have two patches for led support on top of your and they are sadly not yet in mainline. Hauke -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath10k-ct: update and use version based on 4.19
On 12/10/18 1:35 PM, Hauke Mehrtens wrote: --- package/kernel/ath10k-ct/Makefile | 10 +- ...h-all-IEs-for-variant-before-falling-back.patch | 8 +- ...-controlling-support-for-various-chipsets.patch | 544 - ...02-ath10k-4.16-use-tpt-trigger-by-default.patch | 39 +- 4 files changed, 580 insertions(+), 21 deletions(-) diff --git a/package/kernel/ath10k-ct/Makefile b/package/kernel/ath10k-ct/Makefile index d47ab8655c..e763135b92 100644 --- a/package/kernel/ath10k-ct/Makefile +++ b/package/kernel/ath10k-ct/Makefile @@ -8,14 +8,14 @@ PKG_LICENSE_FILES:= PKG_SOURCE_URL:=https://github.com/greearb/ath10k-ct.git PKG_SOURCE_PROTO:=git -PKG_SOURCE_DATE:=2018-09-29 -PKG_SOURCE_VERSION:=b9989fbd5d6e3269b3e49ab3ec71b4174a02209e -PKG_MIRROR_HASH:=67bb1c81518aea5880757d521023db25190d9cca21ba67bf1c7e577efd287430 +PKG_SOURCE_DATE:=2018-11-01 +PKG_SOURCE_VERSION:=6c3a6262317f3240013014e79a570693009c0235 +PKG_MIRROR_HASH:=15c832dd49064c9b03c7012b1a50bfb3000227a750f830e832c5fd1f1fe8bfdf Hello, I just pushed the most recent code. Nothing critical, so it can be used later. Are there any other patches you'd like to see applied to my 4.19 ath10k-ct driver to make inclusion in openwrt easier? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ipq806x: add ath10k calibration data MAC addresses patching
On 11/14/2018 11:53 AM, Felix Fietkau wrote: On 2018-11-14 20:39, Ben Greear wrote: On 11/01/2018 03:18 AM, Felix Fietkau wrote: On 2018-10-28 17:39, Christian Lamparter wrote: Ben Greear reported in his patch: |Subject: netgear r7800: Fix mac address of radios. | |Reloading the driver causes the phyX to change, and that |caused the MAC address to change. This is because all ODM/OEMs except QCA bothered to write the correct MAC address for the ath10k wifi into the calibration data. I don't think that's a strong enough reason to further propagate the messy calibration data patching. How about checking the sysfs device path in the hotplug script instead to make sure we're changing the MAC for the right wifi device? Would this mean that the NIC is loaded with one (potentially bogus) MAC, and then hotplug would very soon after set the proper MAC? If so, that is liable to mess up stock ath10k firmware since it will not properly calculate its rx-bssid mask. To improve MAC address handling, we should probably call pdev_set_base_macaddr_cmdid before bringing up the first vif and use the first vif MAC address there. That might help in general, though not sure exactly how well that is implemented in stock QCA firmware.. My ath10k-ct doesn't need that to do proper bssid-mask, and I'd still like the 'phy' to have the correct MAC address, so I still think MAC should be proper from the very first if at all possible. I tried an earlier version of Christian's patch and it works well for me on the r7800. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ipq806x: add ath10k calibration data MAC addresses patching
On 11/01/2018 03:18 AM, Felix Fietkau wrote: On 2018-10-28 17:39, Christian Lamparter wrote: Ben Greear reported in his patch: |Subject: netgear r7800: Fix mac address of radios. | |Reloading the driver causes the phyX to change, and that |caused the MAC address to change. This is because all ODM/OEMs except QCA bothered to write the correct MAC address for the ath10k wifi into the calibration data. I don't think that's a strong enough reason to further propagate the messy calibration data patching. How about checking the sysfs device path in the hotplug script instead to make sure we're changing the MAC for the right wifi device? Would this mean that the NIC is loaded with one (potentially bogus) MAC, and then hotplug would very soon after set the proper MAC? If so, that is liable to mess up stock ath10k firmware since it will not properly calculate its rx-bssid mask. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Custom cases for Netgear r7800?
This is a bit off topic, but I'm curious if anyone has developed or knows of someone selling customized cases for the Netgear r7800 (or similar AP with similar radios and 128+MB of storage and 512+MB of RAM). In particular, I'd like to get access to the serial port in a nice way, and probably have either more generic branding or maybe my own custom branding. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Proposal for managing the kernel patches.
I just had a good discussion with jow about this on irc, thought I'd put my ideas in email form in case others are interested. In my opinion, it is difficult to develop against the current model of local kernel patches and backports patches. So, I am thinking something like this might be a better approach. Fork the kernel that we want to use for a base (4.19, for instance). Apply the existing patches one at a time to this tree. Push this tree to github. Auto-create tarballs as needed, put them somewhere openwrt can download them. Now, openwrt can select a kernel to use, which is one of these tarballs during compile time. It should be easy to select different kernels with a small makefile tweak (and no need to deal with local patches conflicting). And, we can do 'stable' backport patches for older kernels like upstream does. In addition, the openwrt kernel can be easily compiled for and installed on a desktop OS which might make debugging easier. When it is time to start developing on a new kernel, clone a new one, use 'git am' to create the old patch-set, and then apply it on the new kernel. Push that tree upstream as a new github repo (so we can easily have a 4.19 kernel as well as 4.14, etc). I'd also like to somehow cram backports into this same tree, but not sure how reasonable that is...maybe not worth the effort. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] netgear r7800: Fix mac address of radios.
On 10/25/2018 04:11 PM, Christian Lamparter wrote:
Hello,
On Thursday, October 25, 2018 11:08:02 PM CEST gree...@candelatech.com wrote:
From: Ben Greear
Reloading the driver causes the phyX to change, and that caused
the MAC address to change. Instead, match on pci-bus which should
be immutable.
Signed-off-by: Ben Greear
Mathias Kresin developped a shell function which can just patch the MACs
into the binary pre-cal files. And it should give you the same result.
I don't have a R7800, so I just copied and pasted the functions from
the ipq40xx target and added the R7800 (along with the D7800 and
R7500v2) as an example. It's all untested. It looks like all other
IPQ806x devices could be converted in a similar fashion.
This appears to work on my R7800, and with the added benefit that the
wlanX interfaces have proper MACs now.
So, looks good to me, and better than my patch.
Thanks,
Ben
---
diff --git
a/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index fa49c250f0..c0e4d940f9 100644
--- a/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -1,5 +1,21 @@
#!/bin/sh
+# xor multiple hex values of the same length
+xor() {
+ local val
+ local ret="0x$1"
+ local retlen=${#1}
+
+ shift
+ while [ -n "$1" ]; do
+ val="0x$1"
+ ret=$((ret ^ val))
+ shift
+ done
+
+ printf "%0${retlen}x" "$ret"
+}
+
ath10kcal_die() {
echo "ath10cal: " "$*"
exit 1
@@ -36,6 +52,29 @@ ath10kcal_patch_mac() {
macaddr_2bin $mac | dd of=/lib/firmware/$FIRMWARE conv=notrunc bs=1
seek=6 count=6
}
+ath10kcal_patch_mac_crc() {
+ local mac=$1
+ local mac_offset=6
+ local chksum_offset=2
+ local xor_mac
+ local xor_fw_mac
+ local xor_fw_chksum
+
+ xor_fw_mac=$(hexdump -v -n 6 -s $mac_offset -e '/1 "%02x"'
/lib/firmware/$FIRMWARE)
+ xor_fw_mac="${xor_fw_mac:0:4} ${xor_fw_mac:4:4} ${xor_fw_mac:8:4}"
+
+ ath10kcal_patch_mac "$mac" && {
+ xor_mac=${mac//:/}
+ xor_mac="${xor_mac:0:4} ${xor_mac:4:4} ${xor_mac:8:4}"
+
+ xor_fw_chksum=$(hexdump -v -n 2 -s $chksum_offset -e '/1
"%02x"' /lib/firmware/$FIRMWARE)
+ xor_fw_chksum=$(xor $xor_fw_chksum $xor_fw_mac $xor_mac)
+
+ printf "%b" "\x${xor_fw_chksum:0:2}\x${xor_fw_chksum:2:2}" | \
+ dd of=/lib/firmware/$FIRMWARE conv=notrunc bs=1
seek=$chksum_offset count=2
+ }
+}
+
[ -e /lib/firmware/$FIRMWARE ] && exit 0
. /lib/functions.sh
@@ -55,6 +94,7 @@ case "$FIRMWARE" in
netgear,r7500v2 |\
netgear,r7800)
ath10kcal_extract "art" 4096 12064
+ ath10kcal_patch_mac_crc $(macaddr_add $(mtd_get_mac_binary art
6) +1)
;;
tplink,c2600)
ath10kcal_extract "radio" 4096 12064
@@ -79,6 +119,7 @@ case "$FIRMWARE" in
netgear,r7500v2 |\
netgear,r7800)
ath10kcal_extract "art" 20480 12064
+ ath10kcal_patch_mac_crc $(macaddr_add $(mtd_get_mac_binary art
6) +2)
;;
tplink,c2600)
ath10kcal_extract "radio" 20480 12064
diff --git
a/target/linux/ipq806x/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
b/target/linux/ipq806x/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
index afa425f075..5e5dd84729 100644
--- a/target/linux/ipq806x/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
+++ b/target/linux/ipq806x/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
@@ -18,11 +18,6 @@ case "$board" in
nec,wg2600hp)
echo $(macaddr_add $(mtd_get_mac_binary PRODUCTDATA 12) $((1 -
$PHYNBR)) ) > /sys${DEVPATH}/macaddress
;;
- netgear,d7800 |\
- netgear,r7500v2 |\
- netgear,r7800)
- echo $(macaddr_add $(mtd_get_mac_binary art 6) $(($PHYNBR + 1)) )
> /sys${DEVPATH}/macaddress
- ;;
tplink,c2600)
echo $(macaddr_add $(mtd_get_mac_binary default-mac 8) $(($PHYNBR
- 1)) ) > /sys${DEVPATH}/macaddress
;;
---
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] trying to acheive close to 1 Gbps with 802.11ac 3x3 mimo ath10k Compex wle900vx
If you are running iperf on a weak-ish AP CPU, then that will be a bottleneck. Run iperf on external system through the AP instead. For TCP, use multiple streams, and first test with Ethernet mode to make sure iperf and/or CPU is not the bottleneck before you move to testing the WiFi interfaces. We can get around 900Mbps UDP download throughput on a 'perfect' setup with 3x3 9880 WLE900VX systems and the ath10k-ct firmware. Forcing MCS rate is not a good idea...tune antennas and/or RF environment so that you do not have to force MCS to get highest encoding rate. Thanks, Ben On 10/05/2018 04:17 AM, David Johnson wrote: I'm trying to see what max speed can be achieved My setup is as follow: Board: Compex WPJ 563 Card Compex wle900vx OS: Libremesh running openwrt 18.06 Driver: ath10k_pci :00:00.0: firmware ver 10.2.4-1.0-00033 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 c41417d0 Firmware: firmware-5.bin_10.2.4-1.0-00041 Physical setup Connected 3 6dBi antennas on each side to CH0, CH1, CH2 port to achieve 3x3 mimo. Distance between 2 devices is 2m on a bench. Set power level on each end to 8 dBm to ensure I don't saturate radios Status of radio Node A iwinfo wlan0-mesh info wlan0-mesh ESSID: "speedtest" Access Point: 04:F0:21:3E:DA:A2 Mode: Client Channel: 48 (5.240 GHz) Tx-Power: 8 dBm Link Quality: 70/70 Signal: -33 dBm Noise: -102 dBm Bit Rate: 6.0 MBit/s Encryption: none Type: nl80211 HW Mode(s): 802.11bgnac Hardware: 168C:003C : [Qualcomm Atheros QCA9880] TX power offset: none Frequency offset: none Supports VAPs: yes PHY name: phy0 Status of radio Node B wlan0-mesh ESSID: "speedtest" Access Point: 04:F0:21:3E:DA:A2 Mode: Master Channel: 48 (5.240 GHz) Tx-Power: 8 dBm Link Quality: 65/70 Signal: -45 dBm Noise: -105 dBm Bit Rate: 6.0 MBit/s Encryption: none Type: nl80211 HW Mode(s): 802.11bgnac Hardware: 168C:003C : [Qualcomm Atheros QCA9880] TX power offset: none Frequency offset: none Supports VAPs: yes PHY name: phy0 Ping between radios root@FlatsEast:~# ping 10.69.0.1 PING 10.69.0.1 (10.69.0.1) 56(84) bytes of data. 64 bytes from 10.69.0.1: icmp_req=1 ttl=64 time=1.29 ms 64 bytes from 10.69.0.1: icmp_req=2 ttl=64 time=1.22 ms 64 bytes from 10.69.0.1: icmp_req=3 ttl=64 time=1.22 ms Used iperf to set throughput Client side iperf -c 10.69.0.1 -P 10 -i 5 -t 120 Server side iperf -s Best performance achieved after waiting for TCP to stabalize: 139 Mbps [ 12] 45.0-50.0 sec 11.8 MBytes 19.7 Mbits/sec [ 11] 45.0-50.0 sec 7.12 MBytes 12.0 Mbits/sec [ 9] 45.0-50.0 sec 8.12 MBytes 13.6 Mbits/sec [ 6] 45.0-50.0 sec 7.75 MBytes 13.0 Mbits/sec [ 8] 45.0-50.0 sec 8.00 MBytes 13.4 Mbits/sec [ 4] 45.0-50.0 sec 7.75 MBytes 13.0 Mbits/sec [ 3] 45.0-50.0 sec 7.75 MBytes 13.0 Mbits/sec [ 10] 45.0-50.0 sec 6.62 MBytes 11.1 Mbits/sec [ 7] 45.0-50.0 sec 7.88 MBytes 13.2 Mbits/sec [ 5] 45.0-50.0 sec 9.88 MBytes 16.6 Mbits/sec [SUM] 45.0-50.0 sec 82.6 MBytes 139 Mbits/sec top: Mem: 47064K used, 78232K free, 188K shrd, 3936K buff, 10564K cached CPU: 19% usr 36% sys 0% nic 0% idle 0% io 0% irq 43% sirq Load average: 4.59 3.06 1.90 3/74 25823 PID PPID USER STAT VSZ %VSZ %CPU COMMAND 3 2 root RW 0 0% 32% [ksoftirqd/0] 24511 4419 root S33320 27% 22% iperf -c 10.69.0.1 -P 10 -i 5 -t 120 Any suggestions Regards David -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New QCA 9984 ath10k-ct beta Firmware available.
A company recently sponsored the work to rebase my 1000 or so ath10k-ct wave-2 firmware on a more recent upstream QCA firmware release. I now believe it is stable enough for wider testing, so I invite any of you using ath10k-ct wave-2 firmware on the 9984 chipset to grab the latest beta from our web site. The version should have '10.4b' in its name, like: 10.4b-ct-9984-xtH-011-4f5617a The older stable wave-2 ath10k-ct firmware is just '10.4'. http://www.candelatech.com/ath10k-10.4.php Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Build failure ath10k-CT without mac80211 debug
-03-16-30827f7d/.built] Error 2 make[3]: Leaving directory '/mnt/ramdisk/koen/firmware/builds/generic_rb912/package/kernel/ath10k-ct' Command exited with non-zero status 2 time: package/kernel/ath10k-ct/compile#0.73#0.24#1.55 package/Makefile:107: recipe for target 'package/kernel/ath10k-ct/compile' failed make[2]: *** [package/kernel/ath10k-ct/compile] Error 2 make[2]: Leaving directory '/mnt/ramdisk/koen/firmware/builds/generic_rb912' package/Makefile:103: recipe for target '/mnt/ramdisk/koen/firmware/builds/generic_rb912/staging_dir/target-mips_24kc_musl/stamp/.package_compile' failed make[1]: *** [/mnt/ramdisk/koen/firmware/builds/generic_rb912/staging_dir/target-mips_24kc_musl/stamp/.package_compile] Error 2 make[1]: Leaving directory '/mnt/ramdisk/koen/firmware/builds/generic_rb912' /mnt/ramdisk/koen/firmware/builds/generic_rb912/include/toplevel.mk:216: recipe for target 'world' failed make: *** [world] Error 2 -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Build failure ath10k-CT without mac80211 debug
t/ramdisk/koen/firmware/builds/generic_rb912/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2018-03-16-30827f7d/.built] Error 2 make[3]: Leaving directory '/mnt/ramdisk/koen/firmware/builds/generic_rb912/package/kernel/ath10k-ct' Command exited with non-zero status 2 time: package/kernel/ath10k-ct/compile#0.73#0.24#1.55 package/Makefile:107: recipe for target 'package/kernel/ath10k-ct/compile' failed make[2]: *** [package/kernel/ath10k-ct/compile] Error 2 make[2]: Leaving directory '/mnt/ramdisk/koen/firmware/builds/generic_rb912' package/Makefile:103: recipe for target '/mnt/ramdisk/koen/firmware/builds/generic_rb912/staging_dir/target-mips_24kc_musl/stamp/.package_compile' failed make[1]: *** [/mnt/ramdisk/koen/firmware/builds/generic_rb912/staging_dir/target-mips_24kc_musl/stamp/.package_compile] Error 2 make[1]: Leaving directory '/mnt/ramdisk/koen/firmware/builds/generic_rb912' /mnt/ramdisk/koen/firmware/builds/generic_rb912/include/toplevel.mk:216: recipe for target 'world' failed make: *** [world] Error 2 -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/3] hosap: Add ibss-key-mgt patch from upstream.
On 01/20/2017 02:06 AM, Felix Fietkau wrote: On 2017-01-20 11:05, Felix Fietkau wrote: On 2017-01-20 00:14, gree...@candelatech.com wrote: From: Ben Greear Signed-off-by: Ben Greear That fix has been in the tree for a few days already :) Sorry, i meant in the LEDE tree. You could just backport it from there. I am unlikely to really use openWrt much, but since I was hacking on it, I figured I would post the patches in case someone else can use them (or in case I purge my tree and need to search email for my patches some day :)) Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
On 11/15/2016 07:00 AM, Bruno Antunes wrote: On 15 November 2016 at 14:55, Ben Greear wrote: The beta-18 release on my web page has the fix and should work fine. Probably soon I will promote the beta-18 to final release status. Any help in testing and verifying the beta works well is welcome. I will also do testing with that version. For clarity can I refer you and your firmware releases in the bug report? It is fine by me. It is a one-line patch to fix the firmware...QCA can ask me as well if they don't figure it out on their own. Thanks, Ben Thanks, Bruno Thanks, Ben On 11/15/2016 06:37 AM, voncken wrote: Hi Ben, Do you plan to release a candelatech firmware with this fix? Regards. Cedric Voncken. -Message d'origine- De : linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless- ow...@vger.kernel.org] De la part de Ben Greear Envoyé : samedi 5 novembre 2016 15:35 À : Sebastian Gottschall; yu-chieh kung; Bruno Antunes Cc : Mauro Mozzarelli; linux-wirel...@vger.kernel.org; OpenWrt Development List; ath...@lists.infradead.org Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue Looks to me like 10.4 defaults to the right value, but possibly there are other issues with it. I tested my CT 10.4 and it worked OK with vlans for me. Thanks, Ben On 11/05/2016 01:05 AM, Sebastian Gottschall wrote: would be good if qca can fix this bug finally in all available firmwares. its a very annoying issue since a long time Sebastian Am 04.11.2016 um 23:23 schrieb Ben Greear: The bug appears that vlan-tx-stripping is unconditionally enabled in at least my firmware. I have re-compiled w/out that flag set, and it appears to work for me. Please download this firmware, rename it firmware-2.bin, make sure you remove/rename any firmware-5.bin (etc) so mine will load, and see if that fixes your problem. Please note that it is very likely you will have to use same MAC address for the VLAN devices that the underlying station uses in order for this to work. https://www.candelatech.com/downloads/tmp/firmware-2-full- community.b in Thanks, Ben On 11/04/2016 02:50 PM, Ben Greear wrote: I can reproduce this in my CT firmware. I'll see if I can fix it, but for stock firmware, it might be that changing the driver to use Ethernet packet type of native-wifi would make .1q vlans work. Thanks, Ben On 11/04/2016 10:28 AM, yu-chieh kung wrote: I met the same problem before, if i modify the 1q header to other value (0xaa00) before go into firmware. I can capture the packet in the air I think the vlan packet is dropped in firmware. 2016-11-04 22:41 GMT+08:00 Bruno Antunes : On 4 November 2016 at 14:18, Mauro Mozzarelli wrote: Since the capability is implemented in software you might be testing the limit of your router's CPU i/o speed. By loading the module in rawmode? The AP is an APU and Sta is an APU2. On 04/11/16 14:13, Bruno Antunes wrote: Hi all, Old thread but I think the issue is still present. I'm running a setup with VLANs with WDS and ath10k cards. To make it work both cards must be loaded in rawmode, AP and Sta, and with no security. I'm using a OpenWrt trunk r49941 and the most recent firmware, 10.2.4.70.58, from Kalle ath10k firmware tree. Although it works the throughput is very bad. Are there any alternatives to improve the throughput. Best Regards, Bruno On 9 December 2015 at 17:24, voncken wrote: -----Message d'origine- De : Ben Greear [mailto:gree...@candelatech.com] Envoyé : mercredi 9 décembre 2015 16:34 À : Cedric VONCKEN; ath...@lists.infradead.org; linux-wireless Objet : Re: ATH10K VLAN firmware issue This only happens when you use STA + WDS, or is .1q broken for you in other cases as well? No, this issue occurs in all modes (STA, STA + WDS, AP). Thanks Cedric. Thanks, Ben On 12/08/2015 06:29 AM, Cedric VONCKEN wrote: I'm testing to transmit frame with 802.1q tag (VLAN). My client is set in STA + WDS and the netdev is bridged with eth0. I have a computer with vlan configuration set connected to the STA eth0. If I try to transmit frames with 802.1q tag, the frames are not sent. I checked with wireless sniffer, and I don't see the frame with VLAN tag (the frames without VLAN tag are sent). I tested with firmware 10.2.4.70.14-2 from kale github, 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2 from openwrt, and in all cases I have the same issue. Thanks for your help. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a
Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
The beta-18 release on my web page has the fix and should work fine. Probably soon I will promote the beta-18 to final release status. Any help in testing and verifying the beta works well is welcome. Thanks, Ben On 11/15/2016 06:37 AM, voncken wrote: Hi Ben, Do you plan to release a candelatech firmware with this fix? Regards. Cedric Voncken. -Message d'origine- De : linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless- ow...@vger.kernel.org] De la part de Ben Greear Envoyé : samedi 5 novembre 2016 15:35 À : Sebastian Gottschall; yu-chieh kung; Bruno Antunes Cc : Mauro Mozzarelli; linux-wirel...@vger.kernel.org; OpenWrt Development List; ath...@lists.infradead.org Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue Looks to me like 10.4 defaults to the right value, but possibly there are other issues with it. I tested my CT 10.4 and it worked OK with vlans for me. Thanks, Ben On 11/05/2016 01:05 AM, Sebastian Gottschall wrote: would be good if qca can fix this bug finally in all available firmwares. its a very annoying issue since a long time Sebastian Am 04.11.2016 um 23:23 schrieb Ben Greear: The bug appears that vlan-tx-stripping is unconditionally enabled in at least my firmware. I have re-compiled w/out that flag set, and it appears to work for me. Please download this firmware, rename it firmware-2.bin, make sure you remove/rename any firmware-5.bin (etc) so mine will load, and see if that fixes your problem. Please note that it is very likely you will have to use same MAC address for the VLAN devices that the underlying station uses in order for this to work. https://www.candelatech.com/downloads/tmp/firmware-2-full- community.b in Thanks, Ben On 11/04/2016 02:50 PM, Ben Greear wrote: I can reproduce this in my CT firmware. I'll see if I can fix it, but for stock firmware, it might be that changing the driver to use Ethernet packet type of native-wifi would make .1q vlans work. Thanks, Ben On 11/04/2016 10:28 AM, yu-chieh kung wrote: I met the same problem before, if i modify the 1q header to other value (0xaa00) before go into firmware. I can capture the packet in the air I think the vlan packet is dropped in firmware. 2016-11-04 22:41 GMT+08:00 Bruno Antunes : On 4 November 2016 at 14:18, Mauro Mozzarelli wrote: Since the capability is implemented in software you might be testing the limit of your router's CPU i/o speed. By loading the module in rawmode? The AP is an APU and Sta is an APU2. On 04/11/16 14:13, Bruno Antunes wrote: Hi all, Old thread but I think the issue is still present. I'm running a setup with VLANs with WDS and ath10k cards. To make it work both cards must be loaded in rawmode, AP and Sta, and with no security. I'm using a OpenWrt trunk r49941 and the most recent firmware, 10.2.4.70.58, from Kalle ath10k firmware tree. Although it works the throughput is very bad. Are there any alternatives to improve the throughput. Best Regards, Bruno On 9 December 2015 at 17:24, voncken wrote: -Message d'origine- De : Ben Greear [mailto:gree...@candelatech.com] Envoyé : mercredi 9 décembre 2015 16:34 À : Cedric VONCKEN; ath...@lists.infradead.org; linux-wireless Objet : Re: ATH10K VLAN firmware issue This only happens when you use STA + WDS, or is .1q broken for you in other cases as well? No, this issue occurs in all modes (STA, STA + WDS, AP). Thanks Cedric. Thanks, Ben On 12/08/2015 06:29 AM, Cedric VONCKEN wrote: I'm testing to transmit frame with 802.1q tag (VLAN). My client is set in STA + WDS and the netdev is bridged with eth0. I have a computer with vlan configuration set connected to the STA eth0. If I try to transmit frames with 802.1q tag, the frames are not sent. I checked with wireless sniffer, and I don't see the frame with VLAN tag (the frames without VLAN tag are sent). I tested with firmware 10.2.4.70.14-2 from kale github, 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2 from openwrt, and in all cases I have the same issue. Thanks for your help. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt- devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http
Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
On 11/07/2016 03:54 AM, Bruno Antunes wrote: On 4 November 2016 at 22:23, Ben Greear wrote: The bug appears that vlan-tx-stripping is unconditionally enabled in at least my firmware. I have re-compiled w/out that flag set, and it appears to work for me. Please download this firmware, rename it firmware-2.bin, make sure you remove/rename any firmware-5.bin (etc) so mine will load, and see if that fixes your problem. Thanks for the fast reply but it only solves "half" the problem. Now the connection between the AP and the Sta can be secure and the driver doesn't need to be loaded in rawmode. Unfortunatly the the throughput is still bad. iperf3 -c 10.10.4.15 Connecting to host 10.10.4.15, port 5201 [ 4] local 10.10.4.16 port 44893 connected to 10.10.4.15 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.01 sec 42.4 KBytes 345 Kbits/sec6 1.41 KBytes [ 4] 1.01-2.01 sec 0.00 Bytes 0.00 bits/sec1 1.41 KBytes [ 4] 2.01-3.01 sec 0.00 Bytes 0.00 bits/sec1 1.41 KBytes [ 4] 3.01-4.01 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes [ 4] 4.01-5.01 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes [ 4] 5.01-6.01 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes [ 4] 6.01-7.01 sec 0.00 Bytes 0.00 bits/sec1 1.41 KBytes [ 4] 7.01-8.01 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes [ 4] 8.01-9.01 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes [ 4] 9.01-10.01 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.01 sec 42.4 KBytes 34.7 Kbits/sec9 sender [ 4] 0.00-10.01 sec 0.00 Bytes 0.00 bits/sec receiver You have a complex setup, so I think it would be best if you could break it into simpler parts to test. First, try just STA to AP, no vlans, and see if you get useful throughput. Then try with VLANs Then, try with WDS. Then try with WDS and vlans. In STA to AP mode with VLANs, it performed well for me. Thanks, Ben iperf Done. Please note that it is very likely you will have to use same MAC address for the VLAN devices that the underlying station uses in order for this to work. Can you please elaborate more? My setup is the folowing. The connection between the AP and Sta is in WDS For the moment all devices are in the same VLAN. client1 --- SW1 AP .. Sta SW2 --- client2 Thanks, Bruno https://www.candelatech.com/downloads/tmp/firmware-2-full-community.bin Thanks, Ben Ben Greear Candela Technologies Inc http://www.candelatech.com -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
