Hi gents, having serious issues with wifi every couple of days. Wifi just drops,especially 5GHz. I'm on 18.06-SNAPSHOT r7274-5a07b4e7f5 anything that I can try?
try one of the latest versions here. There have been some versions after yours
With built R7800-master-r8134-a6add47869-20180926, on first Luci Login, I got the message to set the password, but I did not get the "set password" button that leads to the set password screen. clicking around, but there was no button.
Do you know how to connect to router and change some settings or files on it?
If you do, go to this directory /lib/firmware/ath10k/QCA9984/hw1.0/ on your router and there should be a board and firmware bin file.
Download this firmware https://github.com/kvalo/ath10k-firmware/blob/master/QCA9984/hw1.0/3.6.0.1/firmware-5.bin_10.4-3.6.0.1-00003 and rename it to firmware-5.bin and overwrite the file in the folder given above, it is an updated wireless driver that has fixed my wifi drops which were happening on 5ghz only for me.
hello,
so it seems that master is moving to the ath10k-ct firmware as default? or am I misreading the commits?
I am wondering if you will make the change and if not could you consider trying to push this commit, https://github.com/openwrt/openwrt/pull/1374
It has fixed my 5ghz wifi dropouts completely, I used to get constant house members telling me the wifi is down again or just extremely slow but ever since I moved to that manually, its been flawless.
Looks like that. So my master build will change along that to -ct.
The basic change by the core devs is getting mac80211 driver stack more near to the versions in Linux kernel tree. Openwrt had accumulated too many wifi patches, decreasing the maintainability. The goal is to use the next LTS kernel driver stack.
http://lists.infradead.org/pipermail/openwrt-adm/2018-July/000857.html
https://lists.openwrt.org/pipermail/openwrt-devel/2018-September/014060.html
The change to -ct is a bit surprising, as that may deviate a bit back from that target.
Not really a Linux guy. But I managed .. google, test and go.
Easy methode WinSCP and connect via SCP protocol. Rename to firmware-5.bin and copy ... reboot router.
I guess I did something correct today. Lets monitor if it fixes the issue.
If it's a newer (better) driver then why isn't it being updated via those update files?
Super THX for this anyway... watching my wifes and sons face turn to me when wifi stops is priceless .. but only once.
Haven't tested that for a while, but there is nothing special in my build that is related to the missing password message block, (but apparently you are actually discussing some other build). But in any case, the button only leads to the normal system admin page, where the password change functionality actually is.
If you feel that it is a generic LuCI bug, you should report that in LuCI issue tracker in Github. Quite possible that something has got broken recently, e.g. in the split of luci-mod-admin-full into three sub-packages.
1 Like
One of the advantages of ath10k-ct is that VHT160 works and the speeds are pretty good, above 900Mbps with an Intel 9260.
I've also been able to get VHT160 working with upstream ath10k, although speeds are not as good. The only patch required (at least in the GB regdomain) is to allow DFS scanning on 160Hz channels, e.g.
--- a/drivers/net/wireless/ath/ath10k/mac.c 2018-09-27 16:09:37.684103300 +0100
+++ b/drivers/net/wireless/ath/ath10k/mac.c 2018-09-27 16:10:05.531503300 +0100
@@ -8143,7 +8143,8 @@
.radar_detect_widths = BIT(NL80211_CHAN_WIDTH_20_NOHT) |
BIT(NL80211_CHAN_WIDTH_20) |
BIT(NL80211_CHAN_WIDTH_40) |
- BIT(NL80211_CHAN_WIDTH_80),
+ BIT(NL80211_CHAN_WIDTH_80) |
+ BIT(NL80211_CHAN_WIDTH_160),
#endif
},
};
@hnyman sorry for off topic... if we have an old config we should select ath10k-ct in kernel config? we should select also the ct firmware?
Also what about leds support?
I always use the short seed recipe to set the .config, so the device default package selection caused also the -ct kmod to get selected automatically.
I just built master-r8166-d9a37d8d1e-20180927 and at the first glance the ath10k wifi LED support is gone with the -ct kmod/firmware. wifi LEDs are dark again 
Probably the ath10k LED config settings need to be modified to apply also for ath10k-ct variants. Might be this line here:
https://github.com/openwrt/openwrt/blob/3fa7e62cec16393d09a914e3c36a14df8353c608/package/kernel/mac80211/Makefile#L361
Actually I have fear that ct source doesn't have less supports at all...
We need to check this and also we should add specific config like ath10k source (enable debugfs and others)
No, the dependency there is a hard one, requiring patches to the ath10k module itself - relaxing the Kconfig dependency alone won't help, the source patches that have been added to ath10k would need porting to ath10k-ct, namely:
Then we are sadly back in the same situation as a few months ago.
At the first glance, the -ct version's source code looks rather similar as the main ath10k. (I quickly looked at a few files handled by the LED support patch. No serious analysis)
But I still wonder about the reason to switch to the -ct version by default. I think that I have seen no discussion about that.
personally some times ago i tested ct firmware and source and i notice some strange behavior with r7800 (a very strange noise from the wifi chip when something there is traffic)
I really can't understand why the switch to ct... I mean we are trying to have version similar to upstream kernel and we use a custom source for ath10k ????
could be a way to not rebase ath10k patch at every kernel version but i don't think this is a good way...
The discussions around this happened mostly on IRC with ath10k-ct upstream, in short the background mostly seems to be that ath10k firmware bugreports fall into a big black void, while ath10k-ct upstream is providing bugfixes and helps with debugging (this was particularly a problem with QCA9880-BR4A - firmware crashes, problems with 802.11w/ pmf, performance issues, etc.). This is mostly about getting help with getting help with firmware bugs, which handles most of the wlan operations for ath10k hardware and is, varying between chipsets, often buggy.
Edit: ath10k-ct, the kernel module, is closely related to ath10k, mostly modified to aid with debugging and to support all features of the ath10k-ct firmware (which is the actual difference/ driving factor here), that doesn't mean it's always at the same version as ath10k.ko. The ath10k-ct firmware (at least the normal/ community versions of it, not the commercial/ HTT-MGT ones, those do depend on ath10k-ct) are supposed to work with the unmodified ath10k.ko as well.
Disclaimer: I haven't really tested ath10k-ct so far and have added a small patch to keep using ath10k and QCA9984/hw1.0/3.6.0.1/firmware-5.bin_10.4-3.6.0.1-00003 on my nbg6817 for now.
so we need to apply that patch or try to push them upstream...
anyway flashed ath10k-ct with ath10k-ct firmware no problem... seems the strange problem with the noise disappeared
if someone wants to test I ported leds patch to candela source
1 Like
Yesterday, I used -ct firmware, get lots of errors. 
after swifting to ath10k, works fine.
A very first test on my nbg6817 is looking fine, the correct (white) LEDs are now working (equivalent to the last ath10k versions in OpenWrt).
Is there any advantage (or disadvantage) to using the ath10k-ct driver instead of the ath10k driver with the ath10k-ct firmware?