Nobody recommended to flash the recovery instance via Luci.
I recommend you to not try to update the recovery instance if you continue to cut corners on linked procedures for two times.
This is not a web interface procedure. You could produce a brick easily.
I was trying to understand the linked procedures, that's why I ended up here.
But your point (and from @hnyman) is taken. I stopped pursuing this goal.
Thanks (both) for your concern.
Sorry for the delay - the problem appeared on both the 80 and 160 MHz channels.
It seems to be fixed in the absolute latest kernel that I installed on my client, or at least close enough to fixed to have gotten me back into the same ballpark.
As of now, I'm running 160 MHz full time, and things have been nice and stable.
How do I do that?
How do you do what?
To be clear, I'm talking about my client not the router. In this case my client is a laptop running Archlinux, so in order to update my kernel to the latest available, I simply updated my packages using the package manager.
I have no idea what your setup is, and every client is different. For example, the iPhone is something completely different.
This is the solution:
Do not use schedutil and increase the minimum frequency to 600000 kHz.
echo 600000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo ondemand > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
About reboot issues:
About radio issues:
I thought you somehow updated the kernel of the router, my apologies.
EDIT:
I finally found the right search term, apparently, some radios cannot broadcast and scan at the same time, so the one on my travel router probably has that capability where the Belkin does not. That answers that!
Alrighty, my belkins have been running fairly well but there is one oddity. The 5g radios apparently work fine, I have 5ghz and 2.4ghz on the same SSID and password, with 802.11r Fas transition on. I also have a set or Orbi RBR20's these Belkins might replace, if I get all the kinks worked out.
Current oddity is on the channel scanning page, the 2.4 ghz radios show all of the other channels / access stations in my neighborhood, but the Belkins do not. I have two of them, configured almost identically, with the 23.05 release installed. Neither of them will show a proper channel scan, they only show their own interface.
I have a GL.Inet Slate plus, running 23.03 I think, it can scan all the 5gh channels and sees the Belkin machines as well as some of my neighbors, but I would like my Belkins to work as well.
There is nothing in either the system log or kernel log that looks like a failure or error.
What would be a good next step to troubleshoot? My OpenWRT install is using the Dangowrt installer that was just update recently, if that helps. I had see some folks saying the radio packages changed or were not included but that does not seem to be the problem, as I can split out my SSID to 5g, connect to it separately, and run an iperf3 test and get good speeds. So the 5ghz radio definitely works.
Thanks in advance,
Mike
Thanks for the help but don't need to be rude. I didn't know people had the same issue as me.
Ondemand is the default governor now. I have it like that. I'll set the min frequency to see if it helps.
Thanks again.
Ah so:
root@OpenWrt-1:~# cat /etc/rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
echo "ondemand" > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
is no longer necessary for those like me that had that?
Exactly. No longer necessary. After removing that line, reboot, and you can run
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor and it will show ondemand.
It's stated in the wiki now.
Thanks, I already found that page, but as far as I can understand, there's no conclusion. So it looks like it's a bug?!
With the default governor changed to ondemand in 23.05, is manually setting scaling_min_freq to 600000 still needed? I know one is not related to the other, however they're both manual steps performed in rc.local.
I think it was related to the default 437500 triggering a lower voltage on some RAM chips, and some devices would freeze upon boot in the lower voltage mode. There was a link to the code where this was identified, however I don't remember seeing if it was actually patched to use the higher voltage at the lower speed.
Is it still recommended to set scaling_min_freq to 600000?
I had to set it today because I was experiencing this on a reboot. The device turned off instead of rebooting. I added the min frequency line on my rc.local file and so far, so good.
Of course, I didn't set a governor because it's ondemand by default.
When you experience those errors, does your 5GHz radio turns off? I didn't see those errors per se, but sometimes the 5GHz radio would stop broadcasting and I had to manually reboot the router.
I now disabled WED and everything's fine so far. I'll keep testing.
Yes, 5GHz radio turns off, 2,4GHz wifi looks unusable, I can login to luci, but after clicking anywhere it says the session timed out and logs me out. The only thing I can do is ssh into the router via a cable connected computer and reboot the router.
I also disabled WED yesterday and waiting for the results.
By the way is there still no point in using AX on these devices? From my own earlier testing I saw no benefit and worsened stability compared to AC. But perhaps things have changed with 23.05?
AX is good in 23.05, try it out.
I stayed with AC 80 MHz in 22.03, AX was not 100% stable.
I switched to AX 80 MHz in 23.05 : rock stable for all devices since 2 weeks.
I have two RT3200s that I use as access points. After upgrading to 23.05.0 one would shut down after a reboot and also lose the 5Ghz radio after a day or two. Setting the min frequency and changing the governor to schedutil seems to have fixed both those problems. The other RT3200 has had no issues at all.