Thanks @odrt for your help,
I don't remember if I ever noticed this "issue" in previous OpenWRT versions.
If it's something related to ath10k chipset+ hardware limitation, then nothing could be done.
I observed the not working 5 GHz channel analysis on my IPQ8065 R7800 since several OpenWrt releases.
I am not sure if this could be fixed in OpenWrt or whether it’s a hardware or ath10k firmware blob related limitation.
Since these days more and more users buy WiFi 6 11ax devices if desired it would be needed to find enough interest into fixing this not critical issue for existing ath10k WiFi 5 11ac targets.
I agree, once you know what's going on, no problem.
In my case will be in some years. Long live to ath10k 
1 Like
On my E8450 with Mediatek MT7915 channel analysis works. But MT7915 has a special hardware for DFS scans
On my Redmi AX6S (also MT7915E) channel analysis does not work if the 5Ghz radio is configured to a DFS channel. See more details here.
So this issue is definitively not sepecifix to ath10k since it is also affecting mt76.
Same here, DFS channel, 802.11h. But on E8450 (UBI) MT7622 with MT7915E for 5 GHz WiFi.
Channel analysis works while data transmission on the same radio is active.
1 Like
Since rules based iptables not in default effective anymore, what is the best practice of QoS with the new release?
From what I've tested and with the help of the community here, both luci-app-sqm and Qosify seem to work as intended on OpenWrt 23.05.0 for SQM QoS.
The best practice would be to setup the Upload speed, Download speed, and the Link Layer Overhead for your connection and let the default configuration handle the rest.
If you have some specific requirements, you might want to try adjusting the default configuration, but it seems to work for most use cases.
The best QoS these days is really SQM, just follow the guide here, set your dl/ul to about 90% of your max etc., you should get +0/+0 bufferloat:
[https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm]
It looks to be software related, I have a R7800 running another third party firmware and you can choose any channel you want including dfs channels
1 Like
In OpenWrt I can choose every hardware supported channel I want, too. Restricted by chosen country code.
I have successfully upgraded the Netgear R7800 to 23.05.0 without any issues.
23.05.0 has considerably lower system load and also lower processor usage on all my systems (EAP615-wall v1, APU3D4). Cool
3 Likes
Thank you - this is indeed what I am seeing, and the 'fix': setting the ageing time for the bridge seems to work.
Any idea why? In adblock-lean, faster processing of blocklists was also reported with 23.05.
1 Like
No idea. Could it be related to changes in the kernel between 5.10 and 5.15? The extra thing I'm running on all devices is chrony (just for fun). Electricity usage remains pretty unchanged. Here's the processor chart:
1 Like
Netgear WNDAP360 is listed as 23.05 supported, but there are two issues that go back to 22.03 which block or hinder installation.
Specifically:
- Serial Baud rate switches from 9600 to 115200 during kernel image boot.
- Lan port is unable to communicate when autonegotiated 1Gbps, but still shows traffic statistics. This is due to an incorrect PLL setting in DTS
I do not believe this device should be shown as supported with publically available images in its current state.
- are there any issues or PRs which describe the issues?
- if you understand the problem, you're half way to fixing it if 1) above don't exist.
1 Like
As a relatively new forum member and not wishing to tread on toes, I did broach the subject in the Developer Forum thread on the WNDAP360 where these issues were discussed, and I initially thought they were included in a PR. Further research shows that this is not the case, and I will most likely be raising issues and PRs of my own. I simply wanted to point out that images for this device haven't been working since 22.03 and will catch out the unwary. I haven't managed to track down when it got broken from the original support effort. I have summarised the issues at the end of that thread.
2 Likes
Didn't see those. Keeping the noise here to a minimum: fixing bugs is (generally) not stepping on toes. Fire away...
1 Like
23.05.1 was tagged, and then shortly after 23.05.2 was tagged on git.
23.05.1 is presumably being skipped then.
3 Likes