@oly
What I am thinking that you downloaded corrupt files frimware? 
Check sha256 if match…
All firmware sha256 is ok!
I don’t know what to say, since this should have been communicated to me by the support team from GL if something is wrong, I am surprised and amazed that no one has reported this problem!
Now I understand that an update will come that will hide these red logs, but it is ok that they are generated, what is not working correctly with my router?
It’s because the default log view is set to “Access log”.
I changed it to “Error log” and I can see exactly the same problem as reported by you.
This has been fixed since 2020, but looks like GL-iNet didn’t apply it
I noticed in a reply above they will apply on next firmware release.
2 Likes
Forgive me if I’m starting to get a bit annoyed with all the questions and my answer might be taken unkindly. I don’t mean it that way, but I would like to clarify things here:
The error messages you are receiving are actually not errors. (Well, technically they are - but they don’t matter as long as everything works) You would know that if you had studied the subject a little. They are simply messages that nginx (the web server) cannot find certain files that are required for luci. “Required” is not to be understood here as “absolutely required”. Luci is ultimately just a website and has nothing to do with the “router” itself.
Be that as it may, these messages are not serious and you have already been told several times to ignore them. Please do so.
OpenWrt is a complete operating system (like Windows) and not just firmware like on a Cisco switch, for example. This means that there is always a certain amount of “noise” in log files and the like. Unfortunately, OpenWrt also requires you to deal with the subject matter more intensively than is the case with “normal” routers.
It’s perfectly OK if you have questions and the people here will be happy to help you - but PLEASE use your own threads and follow the instructions of other users. It gets very, very, very confusing if you ask the same questions in different areas in different order.
3 Likes
-
Recording irrelevant events can create performance issues and will create useless log to debug something.
-
This has been fixed since 2020
-
GL-iNet will fix it on the next firmware as they wrote above.
The fix is, btw, that they just stopped logging those errors 
They did not fix it, they just made them disappear.
2 Likes
Exactly. Go to item 1 from my previous answer.
Current version 4.5.6, if I set the dark theme, the first time I disconnect and return to the software interface, it doesn’t remember which theme it has set, it returns to the default theme, browser waterfox.
1 Like
I did not loss of theme settings by disconnecting the router.
The theme settings are not stored in the router, is in the browser, so if you change browsers the theme configuration will lost!
4 Likes
Or if you delete data, example cookies
I switched to 160Mhz and I started to see the disconnection issue:
Yep, same issue for me - but with Flint2 in general, no matter on which firmware version.
I have no issues on my side, weird… the only thing I did was to reset the firmware after upgrade and enter all information again.
What kind of devices do you have on 160mhz ? do you have anything else connected to the router like usb devices ? any other wifi routers and such that might cause interference ?
My uptime is 4 days now which is decent considering I was getting crashes every 3-4 hours.
@Renato Intel devices as well?
When you set the band to use 160mhz, is there a command you can run on the router to make sure it is actually enabled ? Also do you need to set some country codes ?
Maybe mine was never set, hence why I don’t see disconnections.
Reasoning, I found this log weird:
Fri Jan 26 06:49:14 2024 daemon.notice hostapd: wlan1: interface state UNINITIALIZED->COUNTRY_UPDATE
Simply check from another device what this device tells you the bandwidth is.
1 Like
You could use WifiMan on Android to see more details of the wifi network.
1 Like
If the device you’re testing from doesn’t support 160MHz then it’ll display what it’s compatible with, which will probably be 80MHz. However, if you access LuCI and go to Status > Channel Analysis > radio1 then you’ll see if the routers using 160MHz.
As for a command, use iw wlan1 info to get information about your 5GHz radio or iw wlan1 scan if you want to get information about all of the APs in your area.
https://openwrt.org/docs/guide-user/network/wifi/wifi_countrycode
You should set the same country code for both the 2.4GHz and 5GHz radios.
1 Like
As the log says, it’s a Google Pixel 7 Smartphone.
USB device is not a problem in this issue, because the log is very clear: the device is disconnected due to inactivity.
Fri Jan 26 06:09:26 2024 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 46:3a:f6:b1:01:8f:e9
Fri Jan 26 06:09:26 2024 daemon.info hostapd: wlan1: STA 46:3a:f6:b1:01:8f:e9 IEEE 802.11: disassociated
Fri Jan 26 06:09:27 2024 daemon.info hostapd: wlan1: STA 46:3a:f6:b1:01:8f:e9 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Why the devices are being disconnected due to inactivity only when the network is set to 160MHz? Who knows!
It’s a Google Pixel 7 Smartphone