Connection monitoring: Yes, I do have it on. But I did consider whether this setting would cause the disconnection as well, and I set it to ping every 60 seconds which should be long enough.
AP that my router connects to: I don’t see there’s any problem or rebooting with it, but I cannot make 100% sure, since it’s public WiFi and I have no access to the admin portal.
5G/2.4G: I’ve tested both frequencies before deciding to stick to 5G. 2.4G gives a download speed at ~80Mbps while 5G can go over 150Mbps (even 200+Mbps if wired connected to MT-3000) in my case.
DFS: I’m in Australia and I don’t think channel 149 requires DFS here (?), according to Wikipedia.
I’m unable to modify bandwidth/channel in repeater mode so I guess I’ll have to use 80MHz.
For now I’ll disable connection monitoring & network switching to see if it helps. And thanks again for your tips
It could be that the amount of devices on the public wifi has reached it’s limit so to let someone on they kick someone off. I had a similar issue at home using hundreds of IoT devices on one network… Had to split the network up into chunks to prevent one single device kicking the entire network one by one to infinity.
Use guest network with IoT. Breaks it up a little. I think someone mentioned you could set up more guest networks but think it may be something you need to do in Luci.
I have. I run 2 beryl’s for my cameras and IoT that are more local to them. Then a flint running 80+ devices then a beryl AX running it’s local devices and doing the multiwan thing… All of those are using main and guest.
I also have another flint ready to connect to the network because more devices are about to be installed. I used to use a mesh system but quickly out grew it…
Some quick updates on how I’ve been trying to debug in the past few days:
I reinstalled the latest 4.5.0 beta (built on 23 Oct) firmware using Uboot to completely troubleshoot the firmware/settings issue, but it didn’t work.
I turned off network switching, network monitoring, or both, neither of which seemed to work.
Given the complexity of the public wireless network environment, I could only blame the problem on the upstream AP.
However, I may have found a temporary workaround: I reinstalled the latest 4.4.6 stable firmware last night, and set the wireless client protocol to 802.11ac (instead of the default ax) in Luci (under Luci > Network > Wireless > Choose the “client” that connects to upstream AP > operating mode). Now my router seems to be working properly for a day. However, if the router reboots, it will be changed back to default ax, and I’m not even sure whether it’s this option or luck that works…
I guess it’s either a problem with the upstream AP or with the router’s wireless driver. I’ll update if any new issues come up.
If you use luci you will probably always get conflicts with the built-in GL. A temporary solution to avoid resetting the settings would be to use this method
Now I can almost conclude that my problem was caused by the upstream AP… I connected to another AP about a week ago, and since then the router has been working flawlessly w/o any disconnection. Anyway I’ll be finishing my travel and returning home by the end of this month, when I’ll test the router on my home network. If it’s working then as well, I’ll close this thread.
PS: Firmware 4.4.6 stable isn’t that stable in my case. I’ve had several times when I couldn’t connect to WiFi after a reboot. I’d say 4.5.0 beta is currently the best firmware for MT3000 with no noticeable issues.
All the 4.x firmwares have loads of bugs and edge cases with Repeater mode. You’ll be lucky to get it stable after hours of tinkering, even with a GL-iNet device as the upstream.
Edit: I came back to update this to be a little more realistic. Even with the 4.x Repeater Mode bugs, there is usually some magic combo of settings where the device will be stable and work well in this mode, as long as you have sufficient signal strength.
Some devices are a lot worse than others, though. Using Creta as a repeater running 4.x (with a Slate AX upstream) is way, way, WAY worse than Creta as a repeater running 3.216. After hours of pain I gave up on the Creta running 4.x, swapped in the Slate Plus with 4.x that I usually keep in my backpack, and it Just Worked immediately with zero fiddling. Yet that same Slate Plus acts strangely in other ways, and requires much more fiddling with some other upstream devices.
GLi devices are really great when they work, I use them every day of my life and am about to buy another one, but there are a lot of bug-related traps even for experienced users on the path to getting them stable for certain use cases, especially on 4.x.
That’s good news to hear and thanks for your team’s work! I’ve been testing my MT-3000 on my home network for the past ~2 weeks and it works well in repeater mode (upstream ASUS RT-AC68U 5GHz, and MT-3000 on firmware 4.5.0 beta). So I guess my problem before was with the upstream AP… Anyway I’ll mark this thread as solved for now.
I installed OpenWRT 23.05.2 and the router is much more stable: no crashes at the moment (6 days and counting) when it used to be between 1 to 3 days max. The 5GHz Wi-Fi is working without issues, so it would be great to push the Dev team for the new open source driver. Otherwise I won’t be able to use the wonderful gl-inet web UI, which is one of the strong selling points of gl-inet routers.
Just a sysupgrade. To revert back to gl-inet firmware you have to use the uboot firmare version (instead of the local upgrade for web Admin Panel) and follow the uboot instructions.
