Ohhh yeah I remember now, that was way back, so the post looks "outdated"
And that statement from GL-iNet is nonsense since it is not unusual for router users to attach external fans to bring router temperatures into acceptable temperature ranges. (That is almost mandatory with some older ASUS routers.) A temperature readout would actually reduce anxiety if the displayed temperature was acceptable.
I wonder if there is an OpenWRT plugin that would display the temperature.
it was removed in 4.9 and any request to get it back was ignored.
if you need it you can get thermal readings by adding luci-apps.
collectd-mod-thermal
3 Likes
This is the way.
I m using 4.9.0 beta2 OP24 on Flint2, If i enable SQM or QOS i lost internet connection, on client and router
So what's the plan for the rest of 2026? Is GL.iNet going to migrate all firmware for supported devices to OP24?
1 Like
I just hope they can update to OP25 and stop releasing beta versions, because the files currently being downloaded are still beta, and they haven't updated any stable versions of OpenWRT in a long time.
1 Like
Rebooting a couple times per day, I guess it crashes, haven’t had time to investigate. Waiting for an update, possible OP25.
Btw, what’s currently the best GL-iNet AP that is supported by vanilla OP25? Any of the WiFi7 do? Still happy with ATX1800 and MT3000 but looking for an upgrade.
Thank you!
Flint2
2 Likes
Everything from such manufacturers should be viewed as beta. They do not make corporation level hardware nor software. Wanna stable -use ‘vanila’ OpenWRT and pretent like it’s a non beta 
Everything is beta to be honest.
Gmail was in beta for a decade…. People may remove word beta, but… to be super stable and non beta - it have to pass MANY YEARS and bugs removed from same codebase, not updatig it to anything new. But people will cry adn theya re crying when see v21 as stable So..either new or stable… there is no such thing as new and stable. As a developer that’s my take on it.
I develop app for past 5 years, we do not put beta on it but man..there is SOOO much to fix till this day..cause apps do not stagnate they evolve and every new thing can and sometimes lead to bugs in ‘old and stable’ places.
As for 4.9.0 OP24 im running it, not using ANY of those new features that came in 4.9.0 (and there is a lot of them) and so far it’s the best version. Previuosly i used 4.8.3 OP24.
In 4.8.3 i had massive problems because of fking 2 wan feature.. they should add feature to DISABLE it… it makes so much problems when not used, or maybe ti was just one of the reasons i had a lot of network restarts inside the router, ports being ‘restarted’. and so on.
1 Like
Is the Radio transmit power adjusted in this latest OP24 firmware? Or still going as strong as it was in 4.8.3?
So… The latest version (beta2) of the op24 firmware for the MT6000 is 5 weeks old. When we can expect a new version?
1 Like
Title: [MT3000 4.9.0-op24 beta1] gl-repeater crash on EAP re-check causes roam to worse/DFS AP, tanking throughput
Firmware: GL-MT3000, v4.9.0-op24 beta1 (2026-05-28 build)
Summary: On a WPA2-Enterprise (PEAP/MSCHAPv2) repeater connection, any disconnect of the sta1 uplink — whether self-triggered ("disconnected due to inactivity") or AP-initiated (AP deauth/reboot) — reliably triggers a Lua crash in gl-repeater's EAP network check during the reconnect attempt. This kills and restarts the whole gl-repeater daemon. After the crash-restart, the repeater's BSS selection logic does not prefer the last-known-good BSSID/channel — it connects to whatever it scans next, which is frequently a DFS channel (52–140). This causes:
-
A multi-second full outage while the daemon restarts and DFS CAC runs
-
The connection landing on a DFS-channel AP instead of the original non-DFS one, often negotiating a fallback legacy rate (54 Mbit/s @ 20MHz instead of full AX/80MHz)
-
No mechanism to reliably lock back onto a preferred non-DFS BSSID — a BSSID set in LuCI's wireless config does get respected on a clean apply, but is overwritten again by the daemon's own scan/connect logic on the next disconnect event
Crash trace (reproduced identically twice, from two different triggers):
gl-repeater[PID]: (gl-repeater.lua:496) /usr/local/lib/lua/5.4/eco/socket.lua:311: bad argument #1 to 'is_ipv4_address' (string expected, got nil)
stack traceback:
[C]: in function 'eco.core.socket.is_ipv4_address'
/usr/local/lib/lua/5.4/eco/socket.lua:311: in upvalue 'ipaddr_to_family'
/usr/local/lib/lua/5.4/eco/socket.lua:323: in function 'eco.socket.connect_tcp'
./files/lib/repeater-nl80211.lua:460: in upvalue 'eap_network_check'
./files/lib/repeater-nl80211.lua:483: in field 'cb'
/usr/local/lib/lua/5.4/eco/time.lua:21: in function </usr/local/lib/lua/5.4/eco/time.lua:19>
Reproduction 1 — self-triggered disconnect:
-
sta1 connected stably to a non-DFS AP (ch36) for ~26 minutes
-
repeater-nl80211.lua:546 disconnected due to inactivityfires (no beacon loss/low ACK preceding it in kernel log — looks like a false positive in the daemon's own inactivity check) -
Reconnect attempt to a new BSSID → crash fires within ~12 seconds of association → daemon restarts (PID change) → lands on a DFS channel (100, then 132) after CAC-bypass
Reproduction 2 — AP-initiated disconnect (different trigger, identical crash):
-
sta1 connected to a non-DFS AP (ch44)
-
AP itself deauths the client (
Reason: 3=DEAUTH_LEAVING, notlocally_generated) — reconnect to same BSSID then times out entirely (AP unresponsive) -
Repeater cycles through 2 more candidate BSSIDs (one DFS ch52, rejected status=17/AP full; one DFS ch108, connects) before the same crash fires again during the EAP re-check on the ch108 connection
-
Daemon restarts, lands on yet another DFS BSSID (ch52, then AP_BUSY-rejected, then back to ch108)
Environment: WPA2-Enterprise/PEAP/MSCHAPv2 against a multi-AP campus network (ASK4 halls of residence, UK) with dozens of BSSIDs across non-DFS (36–48) and DFS (52–140) channels.
Ask: Has anyone else hit this specific is_ipv4_address crash in eap_network_check? Is there a fix already in a later build, or should I file this separately? Happy to provide full logread/kernel log exports if useful.
Forum thread: 4.9.0-OP24 discussion for MT6000 and MT3000