It's funny how the router works perfectly for x days, and after 15, 20 days, it starts doing strange things. 5ghz or 2.4ghz wifi fails, for example. If you restart it everything works fine again. Is there a stack that fills up over time? any minor errors or something that over time ends up blocking the functions?

Here is the link to the ath10k archives
http://lists.infradead.org/pipermail/ath10k/

1 Like

Installation of some Kernel-modules not working/wrong version installed:

Hey,
using the last NSS-Build OpenWRT 2021.x (and before) I have issues with installation of kernel-mods like kmod-vxlan and kmod-iptunnel6. In all cases the dependency of the kernel is different to the installed one (required Version 5.4.188-1-ffa05ea8.., installed is 5.4.188-1-74e47c97..).

Current image: [R7800-20220415-Stable2102NSS-sysupgrade.bin]
Customfeeds: src/gz nss_packages https://github.com/ACwifidude/openwrt/tree/openwrt-21.02-nss-qsdk10.0/bin/targets/ipq806x/generic/packages-Stable2102NSS

opkg install kmod-iptunnel6_5.4.188-1_arm_cortex-a15_neon-vfpv4.ipk
Unknown package 'kmod-iptunnel6'.
Collected errors:

  • pkg_hash_check_unresolved: cannot find dependency kernel (= 5.4.188-1-ffa05ea87f5d82a3d5bcf2087768d91a) for kmod-iptunnel6
  • pkg_hash_fetch_best_installation_candidate: Packages for kmod-iptunnel6 found, but incompatible with the architectures configured
  • opkg_install_cmd: Cannot install package kmod-iptunnel6.

How can I solve this issue?

Ok, found the answer in this thread in Feb'21 - kmod´s needs to be compiled into the kernel because of the changed kernel-hash-value.

So question to ACWIFIDUDE: would it be feasible to at least compile
kmod-ipsec4
kmod-ipsec6
kmod-iptunnel6
kmod-ipt-ipsec
iptables-mod-ipsec
into to your builds - seems to be used by a couple of network functions. Also I would like to ask for
kmod-vxlan
even I know that this is mostly not mainstream...

You can download the required kmod here and install it manually with opkg:

Edit: Sorry I didn't read thoroughly from the above post. I think you need to upgrade to the latest 21.02 NSS first and then you can use the ipk from the repository. It needs exact kernel version match to install the ipk. I don't know if we can retrieve older ipk or not from the repo as it is constantly rebased to the newest version.

Edit 2: After comparing the kernel hash, I think you are installing the ath10k version instead of the -ct one so use this package instead:

Hi adzil,
thanks, but I tried that already and it didn´t worked. And as mentioned in this thread in Feb'21 it would not work in that way, because the repository is just a mirror of the openwrt-github-rep and that´s why it requires a different hash.

I am using the Stable2102NSS without ath10k...

Hmmm weird, because looking at the package manifest the kernel hash requirements are the exact match with the installed kernel you mentioned before (5.4.188-1-74e47c97...).

https://github.com/ACwifidude/openwrt/blob/be3cb22fcc93fd597f02269154848dd428a6a20c/bin/targets/ipq806x/generic/packages-Stable2102NSS-ath10k/Packages#L4900

Seems like these are not just bug fix releases.
I think there are new features as well, like this one for example
http://lists.infradead.org/pipermail/ath10k/2022-April/013511.html
I can only say that I have a laptop with Mediatek WI-Fi 6 Wlan NIC in a distant room and it made 250/150Mbps with the older firmware.
Now at exactly the same place and distance it makes 320/200Mbps with latest version 00157.

I have a Huawei smartphone that had really low (30-40Mbps) Wi-Fi download speed when blue-tooth is on. With blue-tooth off it can reach 250Mbps.
With latest 00157 with blue-tooth on now it can reach 150Mbps down speed.
Using WPA3 encryption in all cases at 5GHz.

2 Likes

Updated the master build yesterday. Will rebase the 21.02 and 22.03 builds in the coming days. Enjoy!

5 Likes

New 21.02 and 22.03 builds posted yesterday! Let me know if there are any issues.

1 Like

Thanks for the link - I didn´t had it before. I was able to install the kmod´s using this link.

1 Like

Yep, those aql patches cause issues. For testing I removed them in my last 21 build. I have an uptime of 51 days right now, my wifi cams have been connected since then without any loss in speed or connection.
Same for all of my other devices phones tvs, laptops etc. have been fine also.

4 Likes

Hi Kong,

Did you remove the AQL patch code or disable AQL using the following kernel settings?

echo 0 > /sys/kernel/debug/ieee80211/phy0/aql_enable
echo 0 > /sys/kernel/debug/ieee80211/phy1/aql_enable

Some people mentioned that disabling AQL with these kernel settings only helped mitigate the issue to some extent on their setup, but did not completely eliminate the problem.

Hi ACwifidude,

Can you please build images without these AQL patches as Kong mentioned?

Thanks!

Hi ACWifidude,

According to Quarky:

"So it looks like a combination of AQL and the new virtual time-based scheduler and looks like it's particularly bad with the ath10k driver. Switching back to the round-robin scheduler stopped all complains about Wi-Fi connectivity for the R7800 (21 days uptime and counting.)"

Can you please communicate with Quarky and build NSS images with AQL enabled but using a round-robin scheduler instead of the new virtual time-based scheduler. WIFI stalling is a real problem starting from 21.02.2 or 22.03, when AQL + new virtual time-based scheduler were added.

Thanks a lot!

All I did for my build was removing both these patches:

package/kernel/mac80211/patches/subsys/382-mac80211-Switch-to-a-virtual-time-based-airtime-sche.patch
package/kernel/mac80211/patches/subsys/395-mac80211-use-coarse-boottime-for-airtime-fairness-co.patch

The mac80211 backport is using the round-robin scheduler with AQL. The above two patches replaces it with the virtual time-based scheduler. The above is for the 21.02 branch.

For master, it is using a newer mac80211 backport that includes the virtual time-base scheduler, so it's more involved if we want to switch back to the round-robin scheduler.

So far my R7800 is running for 36 days without complains .... yet ... touch wood.

1 Like

This is what I did in my 21.02.2 build from @ACwifidude, I didn't notice any real difference in behavior.

I recently rebased the 22.03 build from @ACwifidude myself to April 30 and kept the settings above (see here). I do use the ath10k driver, not the -ct driver. I manually replaced the ath10k firmware with the most recent one (see here). Since then, no issues I had have come back:

root@OpenWrt:~# uptime
 13:48:11 up 10 days,  2:22,  load average: 0.00, 0.02, 0.00
1 Like

Hi quarky,

Are you using the ath10k driver/firmware or the ath10k-ct driver/firmware on your setup?

Thanks.

Hi D43m0n,

I did the same according to your original post and so far so good (also faster throughput than the default ath10k-ct), but I need to wait longer to see if the problem is no longer existing. I had to reboot my router several days ago due to some other non-related issue.

Thanks.

I removed the patches completely, while the aql workaround solved the occasional hang I had a crash with reboot once, so decided to remove the patches and the build is now rock solid. Since there are no important fixes in trunk I decided to let it run before I build and test flash a new one.

could this be related to wifi disconnections over the days? those command disable it correctly then? or do you have to compile without the patches?