Agreed. We should believe and troubleshoot because everyone’s setup is different.
I was referring to blanket statements about stability and preventing the perception that you have to convert drivers right away. Everyone’s mileage varies and we are in good shape that we have two different driver options. I’d definitely advocate to start with the CT drivers first 
Hold on, does the vanilla ath10k driver work now? Last time I checked, this was before the port to kernel 5.4, it was unusable due to crashes (this is the bug report).
It is still unusable in master. I tried last week.
(Note that situation is different in 19.07, so the context for each comment is important)
it's incredible that an upstream driver is that unstable....
Not sure if it is the pure upstream driver, or the impact of the OpenWrt mac80211 patches.
The CT driver is OK. The CT firmware is the problem. It really depends on your clients. And you can't blame the clients when they work just fine with the old firmware and other APs. There are real issues out there in the CT firmware, if they don't affect you, it doesn't mean they don't exist, just check the github issues for CT.
They did release the driver source, but not the firmware
Hi everyone,
I'm a newbie to openwrt and the R7800. I'm trying to flash hymnans latest build using the method outlined in post 5 and from the netgear site. I've manually changed TCP/IPv4 properties to:
IP address => 192.168.1.10
Subnet mask => 255.255.255.0
Default Gateway => 192.168.1.1
I've held the reset button while powering on and waiting for the white flashing light. When PUT the .img file using jounin's tool it gets stuck at start with message block #0.
Using command prompt method:
tftp -i 192.168.1.1 put [firmware filename].img
I'm now getting the error message "connect request failed"
Any advice would be much appreciated. Thank you in advance.
You can try flashing via the stock netgear web interface, it should work. Guides normally say to use tftp but the web interface should also work.
What's the difference between htt-mgt, full-htt-mgt and full flavors? Which one would one normally want to use or which flavor does OpenWRT use by default?
Answer from here:
https://github.com/greearb/ath10k-ct/issues/121#issuecomment-619420575
@hnyman I've been testing Hauke's mac80211-5.6 on ipq806x/ nbg6817 (2*qca9984) and ipq40xx/ map-ac2200 (2*ipq4019+qca9888) with mainline ath10k for almost a day now, which seems to fix the SWBA overrun (FS#2480) so far.
[ 23.552657] Loading modules backported from Linux version v5.7-rc2-0-gae83d0b416db
[ 23.553644] Backport generated by backports.git v5.7-rc2-1-0-gc0c7d2bb
ipq8065/ nbg6817:
[ 23.664944] ath10k_pci 0000:01:00.0: assign IRQ: got 35
[ 23.665337] ath10k_pci 0000:01:00.0: enabling device (0140 -> 0142)
[ 23.665418] ath10k_pci 0000:01:00.0: enabling bus mastering
[ 23.665988] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[ 36.364777] ath10k_pci 0000:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
[ 36.364824] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[ 36.377088] ath10k_pci 0000:01:00.0: firmware ver 10.4-3.10-00047 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 19ca6df2
[ 38.659436] ath10k_pci 0000:01:00.0: board_file api 2 bmi_id 0:1 crc32 85498734
[ 42.422100] ath10k_pci 0000:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 512 raw 0 hwcrypto 1
[ 42.486143] ath: EEPROM regdomain sanitized
[ 42.486157] ath: EEPROM regdomain: 0x64
[ 42.486169] ath: EEPROM indicates we should expect a direct regpair map
[ 42.486194] ath: Country alpha2 being used: 00
[ 42.486204] ath: Regpair used: 0x64
[ 42.492418] ath10k_pci 0001:01:00.0: assign IRQ: got 37
[ 42.493006] ath10k_pci 0001:01:00.0: enabling device (0140 -> 0142)
[ 42.493104] ath10k_pci 0001:01:00.0: enabling bus mastering
[ 42.493734] ath10k_pci 0001:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[ 42.791992] ath10k_pci 0001:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
[ 42.792048] ath10k_pci 0001:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[ 42.803254] ath10k_pci 0001:01:00.0: firmware ver 10.4-3.10-00047 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 19ca6df2
[ 45.134338] ath10k_pci 0001:01:00.0: board_file api 2 bmi_id 0:2 crc32 85498734
[ 48.982782] ath10k_pci 0001:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 512 raw 0 hwcrypto 1
[ 49.046560] ath: EEPROM regdomain sanitized
[ 49.046578] ath: EEPROM regdomain: 0x64
[ 49.046687] ath: EEPROM indicates we should expect a direct regpair map
[ 49.046714] ath: Country alpha2 being used: 00
[ 49.046725] ath: Regpair used: 0x64
ipq4019/ map-ac2200:
[ 21.906310] ath10k_pci 0000:01:00.0: enabling device (0140 -> 0142)
[ 21.907034] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[ 22.553060] ath10k_pci 0000:01:00.0: qca9888 hw2.0 target 0x01000000 chip_id 0x00000000 sub 0000:0000
[ 22.553108] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[ 22.565537] ath10k_pci 0000:01:00.0: firmware ver 10.4-3.9.0.2-00054 api 5 features no-p2p,mfp,peer-flow-ctrl,allows-mesh-bcast,no-ps crc32 68d870ac
[ 22.917507] ath10k_pci 0000:01:00.0: board_file api 2 bmi_id 0:17 crc32 f228337a
[ 24.822196] ath10k_pci 0000:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 512 raw 0 hwcrypto 1
[ 24.934902] ath: EEPROM regdomain sanitized
[ 24.935001] ath: EEPROM regdomain: 0x64
[ 24.935051] ath: EEPROM indicates we should expect a direct regpair map
[ 24.935187] ath: Country alpha2 being used: 00
[ 24.935240] ath: Regpair used: 0x64
[ 25.918886] ath10k_ahb a000000.wifi: qca4019 hw1.0 target 0x01000000 chip_id 0x003b00ff sub 0000:0000
[ 25.918932] ath10k_ahb a000000.wifi: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[ 25.930761] ath10k_ahb a000000.wifi: firmware ver 10.4-3.6-00140 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 ba79b746
[ 26.006428] ath10k_ahb a000000.wifi: board_file api 2 bmi_id 0:20 crc32 e2dfaa91
[ 27.413294] ath10k_ahb a000000.wifi: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 512 raw 0 hwcrypto 1
[ 27.435282] ath: EEPROM regdomain sanitized
[ 27.435309] ath: EEPROM regdomain: 0x64
[ 27.435323] ath: EEPROM indicates we should expect a direct regpair map
[ 27.435359] ath: Country alpha2 being used: 00
[ 27.435371] ath: Regpair used: 0x64
[ 27.850676] ath10k_ahb a800000.wifi: qca4019 hw1.0 target 0x01000000 chip_id 0x003b00ff sub 0000:0000
[ 27.850741] ath10k_ahb a800000.wifi: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[ 27.864029] ath10k_ahb a800000.wifi: firmware ver 10.4-3.6-00140 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 ba79b746
[ 27.911790] ath10k_ahb a800000.wifi: board_file api 2 bmi_id 0:21 crc32 e2dfaa91
[ 29.329734] ath10k_ahb a800000.wifi: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 512 raw 0 hwcrypto 1
[ 29.352251] ath: EEPROM regdomain sanitized
[ 29.352281] ath: EEPROM regdomain: 0x64
[ 29.352295] ath: EEPROM indicates we should expect a direct regpair map
[ 29.352330] ath: Country alpha2 being used: 00
[ 29.352342] ath: Regpair used: 0x64
A quick test with ath10k-ct also appears to be fine.
That would be great, as there would again be a real possibility to select between mainline ath10k and ath10k-ct
Hi everyone,
Completely new to the topic and still considering the router to buy for use with openwrt (R7800 vs. NBG6817).
Regarding NSS firmware I saw the following UC https://github.com/qca/nss-firmware
That’s not a starting point?
Will this require a move to kernel 5.6 or 5.7 or is it being backported to 5.4 also?
No need to move to kernel 5.6 or 5.7 (which are not supported by OpenWrt and likely will never be)
OpenWrt mac80211 logic is backport of the wifi driver from kernel X to the current kernels (5.4, 4.19, 4.14). so, Hauke has wifi driver from kernel 5.7-rc2 backported to our 5.4
Is it only me or Android TV's fails to connect after flashing OpenWRT.
I've flashed the image from official channel also @hnyman 's build it fails to connect
Two days, 22:28 hours, welcome the sudden crash out of nowhere - back to ath10k-ct.
out of curiosity, what crashed? ath10k firmware, kernel, or something else?
I was using a build from a few days ago and experienced loss of multiple functions (including inability to connect by wifi but one wifi client stayed connected and functional, wired connections still possible, ssh and scp working, but openssh-sftp not, I think "iw" not working, etc.) and observed only a kernel warning.
As I was using ath10k-ct I passed the dmesg on to greearb. He suspects its not ath10k related but looked like a memory corruption of some sort. Only happened once; however my load average was always a tad high on this build with hostapd the likely culprit for the higher than normal load.
Today's build via image builder seems better.
Any event, you might want to try again with a newer build.
HTH.
Sadly I don't know, the nbg6817 just rebooted (probably invoked by the watchdog) during normal operations (only two wireless connections at the time, all background chatter, not intensive use at all), but it has all the signs of (FS#2480) - aside from "SWBA overrun" messages. The MAP-AC2200 (same OpenWrt revision/ ath10k version) connected to it as WDS client (2*ipq4019+qca9888) remained unaffected so far.