I found a small bug about uptime work incorrect.
In router page has limit 30 or 31 days then 0. I did not restart router.
Goodcloud saying 58 days which is correct uptime.
Problay all frimwares version 
1 Like
I guess the future for this device is waiting for the next stable OpenWRT release, then you can install it to take full advantage of the hardware
PPPoE is working fine?
I noticed some users have mentioned experiencing disconnection issues.
It depends on so many different settings, setups and stuff that you can’t really say “working” / “non-working”
For me the Flint2 is working nearly since the first time I removed the bubble wrap.
Since the developers have never released a stable, bug-free version since the router was released and don’t seem to care about it in the time that has passed, you will have to get used to using OpenWRT or a fork of it (e.g. ImortalWRT).
1 Like
Mine Pppoe is working fine in UK. There was different Vlan ID in UK broadband providers.
2 Likes
Thanks… I am rather concerned as to how long this router (indeed all of GL.inet’s routers) will continue to receive ongoing firmware updates in line with OpenWRT, let alone for security updates?? I do not want to install OpenWRT… I am paying for the convenience of the GL.inet GUI.
1 Like
Since you want to use a simplified stock UI you’d probably be better off with the TUF-AX6000 or TUF-AX4200 if you can find them on sale. Then just use NextDNS if you want to block ads.
Both the TUF-AX6000 and TUF-AX4200 support OpenWrt, so you could install OpenWrt in the future once updates from ASUS slow down.
I find this comment too harsh. The developers are overly eager to develop two different versions of firmware for the MT6000 that are largely free of errors. They already are for my use case. Claiming they don’t care is exaggerated and inappropriate.
7 Likes
this firmware seems to be working well. Will the fixes be in the next firmware update?
I’m still using the 4.5.2 firmware mine shipped with after reading the vast amount of problems people have been having after updating to later version. This is my first GL.iNet product and TBH, I feel let down by it. Seems like many of these issues should have been found out and addressed in the beta testing, rather than having people who paid good money for a product be testing and troubleshooting.
3 Likes
The fixes will be in the firmware 4.5.9.
2 Likes
Thanks for reporting. It is a bug. Will fix.
2 Likes
Is there any estimate on when version 4.5.9 will be available?
new firmware, will it improve anything?
1 Like
I have firmware version 4.5.8 installed.
And the router is quite stable for my use.
It is cascaded to my provider’s ONT and provides me with a 1G-2G connection on the ETH interface and 1.5G on WiFi 5Ghz simultaneously.
The 2.4Ghz WiFi is more unstable, but for home automation it is sufficient.
It also handles IPv6 perfectly.
Then I use AdGuard Home (which, thanks to a script, is constantly updated to the latest version available) and WireGuard (as clients a GL-iNet Beryl AX and Notebooks) and these also work perfectly.
So, for my use, it is an excellent router (of course, always waiting for a firmware that will make the device even more stable) and then the GL-iNet GUI is incomparable while maintaining the possibility via LuCI to make more specific configurations on OpenWRT.
1 Like
I’m eagerly waiting to also report that this device is stable for me.
Unfortunately I seem to have 1 client in the wifi network that seems to be able to cause an issue.
Fri Apr 12 08:17:47 2024 daemon.info hostapd: wlan1: STA mac_address IEEE 802.11: authenticated
Fri Apr 12 08:17:47 2024 daemon.info hostapd: wlan1: STA mac_address IEEE 802.11: associated (aid 4)
Fri Apr 12 08:17:47 2024 daemon.notice hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED mac_address off
Fri Apr 12 08:17:48 2024 daemon.notice hostapd: wlan1: AP-STA-CONNECTED mac_address auth_alg=open
Fri Apr 12 08:17:48 2024 daemon.info hostapd: wlan1: STA mac_address WPA: pairwise key handshake completed (RSN)
Fri Apr 12 08:17:48 2024 daemon.notice hostapd: wlan1: EAPOL-4WAY-HS-COMPLETED mac_address
Fri Apr 12 08:18:00 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) mac_address
Fri Apr 12 08:18:00 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.8.151 mac_address
Fri Apr 12 08:18:00 2024 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.8.151 mac_address
Fri Apr 12 08:18:00 2024 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.8.151 mac_address
....
Fri Apr 12 11:14:03 2024 daemon.notice hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED mac_address dynamic
Fri Apr 12 11:16:02 2024 daemon.notice hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED mac_address off
Fri Apr 12 11:18:11 2024 daemon.notice hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED mac_address dynamic
Fri Apr 12 11:19:55 2024 daemon.notice hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED mac_address off
Fri Apr 12 11:19:57 2024 daemon.notice hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED mac_address dynamic
Fri Apr 12 11:19:58 2024 daemon.notice hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED mac_address off
Fri Apr 12 11:20:00 2024 daemon.notice hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED mac_address dynamic
Fri Apr 12 11:20:01 2024 daemon.notice hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED mac_address off
This seems to be an openwrt bug.
From the moment I observe the last log lines the client in question gets limited to 50Mbps.
I also had the impression the whole wifi network got slowed down, but that is a bit harder too prove.
After some searching I found that you can go to the advanced setting of the wifi card and change the “MIMO Power Save Mode” to No SMPS. This seems to resolve the issue. (Credits go to Fredo on the OpenWRT issues tracker - "STA-OPMODE-SMPS-MODE-CHANGED" what that mean? - #26 by Fredo - Network and Wireless Configuration - OpenWrt Forum)
Update:
The issue doesn’t seem to be entirely gone.
After a period of inactivity, I got back at the laptop in question and noticed the wlan speed got stuck again at 50 Mbps.
I observe this in the router log:
Fri Apr 12 12:02:04 2024 daemon.info hostapd: wlan0: STA mac_address IEEE 802.11: authenticated
Fri Apr 12 12:02:04 2024 daemon.info hostapd: wlan0: STA mac_address IEEE 802.11: associated (aid 3)
Fri Apr 12 12:02:05 2024 daemon.notice hostapd: wlan0: AP-STA-CONNECTED mac_address auth_alg=open
Fri Apr 12 12:02:05 2024 daemon.info hostapd: wlan0: STA mac_address WPA: pairwise key handshake completed (RSN)
Fri Apr 12 12:02:05 2024 daemon.notice hostapd: wlan0: EAPOL-4WAY-HS-COMPLETED mac_address
Fri Apr 12 12:02:07 2024 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.8.151 mac_address
Fri Apr 12 12:02:07 2024 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.8.151 mac_address
Fri Apr 12 12:02:16 2024 daemon.notice hostapd: wlan1: DFS-CAC-COMPLETED success=1 freq=5260 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5290 cf2=0
...
Fri Apr 12 12:11:39 2024 daemon.info hostapd: wlan1: STA mac_address IEEE 802.11: authenticated
Fri Apr 12 12:11:39 2024 daemon.info hostapd: wlan1: STA mac_address IEEE 802.11: associated (aid 2)
Fri Apr 12 12:11:39 2024 daemon.notice hostapd: wlan0: Prune association for mac_address
Fri Apr 12 12:11:39 2024 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED mac_address
Fri Apr 12 12:11:41 2024 daemon.notice hostapd: wlan1: AP-STA-CONNECTED mac_address auth_alg=open
Fri Apr 12 12:11:41 2024 daemon.info hostapd: wlan1: STA mac_address WPA: pairwise key handshake completed (RSN)
Fri Apr 12 12:11:41 2024 daemon.notice hostapd: wlan1: EAPOL-4WAY-HS-COMPLETED mac_address
Fri Apr 12 12:11:44 2024 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.8.151 mac_address
Fri Apr 12 12:11:44 2024 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.8.151 mac_address
Fri Apr 12 12:12:09 2024 daemon.info hostapd: wlan0: STA mac_address IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Fri Apr 12 13:08:56 2024 daemon.notice hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED mac_address dynamic
Disconnecting and connecting again to the wifi resolves the speed issue…
2 Likes
Can you give us some details about how to do this? Thanks.
This might be a long shot, but is there a way I can take a backup of the entire flash inside the router?
Like how you can create an image of a disk… I’d like to experiment with some of these beta versions and also mess about with using OpenWRT natively etc, however I’d like a way to quickly restore everything back to how I have it set up right now.
I’ve got quite a few customisations that currently take more than an hour to get everything back to how I like it, so being able to image the flash and restore it back would be useful.
I’ve seen a method for SD cards but apparently it doesn’t work with NAND.
1 Like