Nothing obscure about this tweak. And only precautionary since I do not experience boot or reboot problems with my device at all, even after a lot of 23.05-Snapshot and RC release sysupgrade related reboots.
If the reports make you feel insecure about the device and you don't already own it: don't buy it. I would still buy it because it's still a great value to me and of course stable.
The alternative to me would be Netgear WAX206, which is currently out of stock everywhere. Or GL-MT6000, which is more expensive, bulkier, should have higher power consumption and I don't need quad core and 2.5 GbE WAN for now.
MT7981B based routers could be the natural dual core successor to E8450 or RT3200. But I see only GL-MT3000 currently supported and this device does not include an integrated switch and could be annoying under load with the active fan based cooling.
Does anyone experience periodic loss of WiFi (only 5 GHz) network.
Belkin RT3200 running master build as dumb AP. Bridger and WED are installed too.
Every few days (~10-20 days) 5 GHz WLAN simply stops working. Restarting only that network doesn't help. Only router reboot cures it.
Never used them. Never had any problems with WiFi loss or any other issues on two RT3200's after the Apple client issue was fixed some time ago. Maybe bridger/wed is a clue? One is a dumb AP and the other is set up as a gateway with WiFi for a family member.
I do set the min clock to 600 Mhz. Other than having to use channel 149 to get the FCC certified transmit power for the device (channel 36 doesn't allow it with OpenWrt), I've no complaints. Really nice devices for the $50 each I spent on them.
I'm just another poorly sampled data point though.
The question would be what should be added to the wiki in this case. My raised min_freq CPU clock speed is based on one report, that this setting increases reboot stability.
I would not add something in the wiki article which could be interpreted as solution as long as we don’t know what’s really happening when the issue occurs and how to avoid or solve it.
I suggest to instead add the information to the wiki that there are several reports of boot and reboot problems, analysis of the root cause and search for solutions is still ongoing. Then people should not take the min_freq setting as false safety.
I added the 600k to my rc.local and it didnt change my reboot issue.
I feel like a loon freezing the thing. but I have it to the point where I can just leave it running now without trying to improve it
I had occasional problems with DFS due to the 5GHz channel being set to "auto". Try changing it to a non-DFS channel and see the problem goes away. If so, that is probably the issue.
I searched this thread, and really wouldnt have any idea how to implement it.
I only saw a question asking if freq minimum or performance governor might be a solution.
But did you execute the command on the cli before the reboot, so it was in effect? If not, then that first reboot before rc.local is executed was done with the old min_freq value, so...
Yes, rebooted twice to ensure that the rc.local was in effect
(to be specific, click reboot, (unresponsive, power & reset do nothing) freeze lol, boots normally with settings intact and the freq min set in startup, click reboot , same.
Freeze, reboots and all settings are as I left them
I have it set as a wireless repeater, that is both client and master on the 5GHz radio, and works fine, but after reboots I do have to restart the radio after the client side has made its uplink connection in order to get the master side working.
I might try turning off all radios before I attempt next reboot , but I have no compelling reason to do so tonight.
Mine was on Channel 36 and 160Mhz with WED, packet steering, hw offloading and sometimes my 5GHz radio went bust. I had to reboot everytime that happened.
I set it up to 80MHz and have been flawless ever since.
At first I thought it was WED's fault, but even if I disabled it, the error happened again.
You do use DFS channels...
160 MHz is practically always partially DFS. (the first 80 MHz starting at channel 36 is not, but the highest 80 MHz is, at least in Europe and USA)
After more testing with 6.1 builds, I discovered abnormally high CPU usage (>30%) for WAN<->LAN traffic suggesting that the NAT hardware acceleration is not working at all. So I suspect hardware NAT is broken with other mediatek devices as well, as the changes causing this issue are in the kernel (see changelog - lots of commits targeting offloading). Now I changed my builds to 5.15 kernel and everything is working fine, i.e. 3% CPU usage with WAN<->LAN traffic and 40% CPU usage with WAN-WLAN traffic showing NAT hardware and WED acceleration back to normal.
