Is anyone else having issues with 160MHz and higher AX channels? I'm trying to set my routers up to use channels between 128 and 157 (those are interference-free), but for some reason, I'm getting errors in hostapd:
The funny thing is, channel 128 on ONE of the two RT3200's I have, works most of the time (but a reboot can kill it, forcing me to manually reload WiFi a few times till it works again). On the other, it just flat out refuses to work.
Setting the adapter to 80MHz + lower channels (up to channel 60) results in no such behaviour.
This started happening on the latest snapshot (previously, 160MHz didn't work at all, but higher channels did).
Doing lots of package upgrades will slowly fill up the rootfs overlay volume. I'd recommend you to periodically update using auc or luci-app-attendedsysupgrade and only do emergency hot-fixes or additional installs using opkg.
This looks like recovery has booted normally and from here you should not upload and flash the *sysupgrade.itb file. And that didn't work? What was the error/what happened?
So this device was healthy and already running UBI formware normally, then you flashed sysupgrade and since then it always drops you to recovery mode (ie. you see only 2.4ghz wifi and configuration won't survive reboot)? Please confirm in detail, so I can understand what's going on.
The recovery you are running comes from v0.5 UBI installer from what I can tell and that should be working fine.
What is happening is probably that the device has crashed and because of that is now starting recovery for you to figure out what was happening and report to us
Please open SSH console on the device and check PSTORE/ramoops content and report back the output:
ls -1 /sys/fs/pstore
cat /sys/fs/pstore/*
After that, you can delete the PSTORE content which should make the device return to boot normally.
rm /sys/fs/pstore/*
Disconnecting the power from the device for 10-15s should also make it forget PSTORE content in RAM and return to normal operation.
root@OpenWrt:~# ls -1 /sys/fs/pstore
root@OpenWrt:~# cat /sys/fs/pstore/*
cat: can't open '/sys/fs/pstore/*': No such file or directory
root@OpenWrt:~# ls -1 /sys/fs/pstore
root@OpenWrt:~# cat /sys/fs/pstore/*
cat: can't open '/sys/fs/pstore/*': No such file or directory
root@OpenWrt:~# cat /sys/fs/pstore/
cat: read error: Is a directory
root@OpenWrt:~#
Yes, very strange indeed. Did you disconnect the power or toggle the power switch maybe? That also clears PSTORE and hence makes it go back to normal boot.
Modify recovery to submit crashlogs somewhere or keep them in additional UBI volume, ..., then remove them from PSTORE and reboot. This is how imagine it for remote-managed unattended devices. Minimal network config as well as URI for submission can be stored in U-Boot env.
Soon LuCI will have notification support, and that will allow to clearly show that the device has booted into recovery mode and also that there are crashlogs in PSTORE. Probably we (any volunteers?) can make a LuCI UI to view or download logs from /sys/fs/pstore (using rpcd file access methods or dedicated rpcd-mod-pstore backend) and also allow to easily clear it to go back to normal boot.
Depends on https://github.com/openwrt/luci/pull/5041
If you want to disable the feature entirely, tell the bootloader not to care:
fw_setenv bootcmd "run boot_ubi"
which will replace the default which is
if pstore check ; then run boot_recovery ; else run boot_ubi ; fi
The last couple of releases, I've been having frequent wifi issues. Both 5ghz and 2.4ghz networks will go down and then come back up a few minutes later. I think it might be related to the recent hostapd change.
This is not caused by channel switching or DFS and there are no logs indicating a reason for the radio/hotspot restart. I'm on r17101-f4e3ff5b07 - would be good to hear if others are having this issue or if anyone has ideas for addressing this.
@daniel The issue happened to me again this night (note i'm the original reporter unless there was a 3rd person before me), again roughly around 23 CET (at 4:30 i've seen kernel msg connecting my LAN cable 5h 50 min after boot, that would make it around 22:40). Sadly I was not aware of your pstore comment, so i went straight to the poweroff to resolve it.
Next time I will be ready along with system logs on USB stick set up using this guide, I expect it to happen after another few days.
@Dopam-IT_1987 note you don't need to flash new system - half a minute poweroff restores original configuration. I did reflash (bricking device) because I thought system was not installed fully and wanted to start over, then I went into TFTP recovery to restore from the bricked state.
