In my case it seems to be due to the numbers of barriers. M1 Mac client, 7m from the router and a single wall in between. When the RSSI gets roughly below -65dBm, TX HE-MCS suddenly drops to 0. RX seems to be largely unaffected.
It seems that the "channel analysis" shows "no data" on the latest master snapshot - r21968-acd8e94d20. Is it an issue only on my router or you have that as well?
Your crash is a little different than the one I'm having, but I am starting to see a common theme here.
I have four RT3200's, configured with VLAN's, and they crash about once or twice a day in direct correlation with how many users hook to them simultaneously.
I have four other RT3200's, configured almost identically but without VLAN's, and they have been pretty stable running for over a month now.
It seems that using VLANs with the Belkin RT3200 is causing kernel dumps, and it happens when interfaces enter and leave promiscuous mode. I have used them by myself on weekends, roaming between them, without any crashes. So it is possible this could be a threading race condition and requires simultaneous connections/roaming to reproduce the crash.
Here's the dump I just had:
2023-02-03 10:46:45|Kernel.Info|WIFI-Dev kernel: [ 1095.244841] br-vlan11: port 2(wlan1.4105) entered disabled state
2023-02-03 10:46:45|Daemon.Error|WIFI-Dev hostapd: VLAN: br_delif: Failure determining interface index for 'wlan1.4105'
2023-02-03 10:46:45|Kernel.Info|WIFI-Dev kernel: [ 1095.335406] device br-lan.11 left promiscuous mode
2023-02-03 10:46:45|Kernel.Info|WIFI-Dev kernel: [ 1095.335542] br-vlan11: port 1(br-lan.11) entered disabled state
2023-02-03 10:46:46|Daemon.Notice|WIFI-Dev netifd: bridge 'br-vlan11' link is down
2023-02-03 10:46:46|Daemon.Notice|WIFI-Dev netifd: VLAN 'br-lan.11' link is down 2023-02-03 10:46:46|Feb 3 10:46:46 WIFI-Dev kernel: [ 1095.389694] Unable to handle kernel paging request at virtual address 00689e8e03f8ea2f
I wonder what would happen if I set a configuration in /etc/config/network for all .1q devices to be in promiscuous mode...? Would it stop them from changing to and from promiscuous mode, potentially solving the crash?
This is not my area of expertise so I hope one of the others can comment. In my case, I gave up on VLANs because I managed to lock myself out of my own outdoor router in playing with them and interfaces, etc, maddeningly requiring climbing a ladder because OpenWrt does not yet have a buttonless failsafe trigger. I don't strictly need VLANs so I gave up.
I am not using them too extensively, just for isolating guess lan and iot devices, not using them too much as there are not many devices, but in my test it worked perfectly.
I use 3 wireless access points and 2 VLANS among the main router and another wireless access point using an etherne tconnection among them with VLANS.
IOT devices can communicate among them using the vlan being connected to any of the two wireless access point.
The RT3200 has the reset button. If you hold it down it goes back to the last full flash and you can start over. I had to twice while setting it up because I put the IP address on the wrong vlan as I turned on full tagging.
You can also have it plugged into a cisco switch and turn tagging on/off as you configure it in case you have a model that doesn't allow you to just reset it like the RT3200 does.
Or you can always set one port to full tagging and one port as an untagged maintenance port, so you can always hook it directly to a laptop. Just make sure to affix a "maintenance port" sticker next to it on the back so pen testers can quickly locate it.
Iv this router but mine is now stuck in recovery and can't seem to get it into production
Iv even tried Tried cat /sys/fs/pstore/* and no file or directory found via SSH. how this happened was I used the web gui to update the firmware and checked the box to keep the settings. After it rebooted it it was working but the WiFi was not so I held down the reset button and then it went to into recovery and no matter what firmware I try it just goes back to recovery
I suggest you try what worked for me, flash 22.03.0-rc1 (link) and then install the package luci-app-attendedsysupgrade. With that you get a new option in luci to update.
Why are the non-UBI downloads still in the repository if they were always broken in the releases after 8/21? I was trying to install 22.03.3 on a new e8450 until I saw the message on the device page and your post here. I have a backup of the mtdx files and expect to stay on OpenWrt, but it would be nice to try it out first with an easy recovery option.
