OP24 for my beloved MT6000 is out for testing.
Where:
MT6000 https://dl.gl-inet.com/router/mt6000/openwrt24
MT3000 https://dl.gl-inet.com/router/mt3000/openwrt24
Let’s install, test and discuss.
Update: OpenWRT 24.10.4 r28959-29397011cc is used for this firmware version.
What is OpenWRT 24, and why is the Flint 2 the only one to have it? How is it different from before?
GL.iNet OP24 Firmware vs Standard Firmware (MT6000 / Flint 2)
OP24 is GL.iNet’s firmware branch based on OpenWrt 24 (newer, more upstream), while the standard GL firmware is a heavily customized OpenWrt build with proprietary components.
Base system
OP24: based on newer OpenWrt (24.x, newer kernel)
Standard: based on older OpenWrt with GL customizations
Wi-Fi drivers
OP24: open‑source drivers
Standard: MediaTek proprietary drivers (via SDK)
Performance
Standard firmware often has better Wi‑Fi range and stability
OP24 may behave differently depending on environment
Features & UI
Both include the GL.iNet web UI and core features
OP24 is closer to “vanilla OpenWrt” under the hood
Philosophy
OP24: more open, modern, and flexible
Standard: more optimized, stable, and user-friendly
The main practical difference is the Wi‑Fi driver stack — everything else is largely similar from an end-user perspective.
Use OP24 if you want:
newer OpenWrt base / kernel
better compatibility with OpenWrt packages
more control and openness
Use standard firmware if you want:
best Wi‑Fi performance and range
maximum stability
a “just works” experience
You can switch between both, but it requires a full reset (no config restore).
From a GUI and feature standpoint, they behave almost identically.
TL;DR:
OP24 = more modern and open.
Standard firmware = more optimized and stable (especially Wi‑Fi).
Is the Flint 2 the only one to get OpenWRT 24 support? Isn't the latest release at v25 now?
The are planning op25 but have no ETA.
Has anyone else noticed that in op-24 v4.9.0, IP masquerading of the wireguard tunnel is not working (fresh install without keeping settings)? I have DPI inspection and Adguard both running as well as Windscribe VPN client if that makes a difference although IP masquarading was fine with these features all on the op-21 version of the firmware on Flint-2! Everything else that I have tried seem to be working fine so far.
Encrypted DNS is not working it always uses Cloudflare instead of the specified provider
I encountered this yesterday and it will work normally if you manually stop “stubby” service by running “service stubby stop” in CLI.
Finally something from this year on op24 
Im testing this weekend 
I was able to update AdGuardHome to version 0.176 via the console. In firmware 4.9.0, the client handling counter is still displayed correctly and appears to be working as expected.
@bruce I found a DNS leak issue in this firmware. When the VPN is enabled and AdGuard Home is running, DNS requests appear to leak through the AdGuard Home DNS IP instead of being fully routed via the VPN DNS. If needed, I can provide log files for further investigation.
Try this solution here
It stopped the leaks for me 
Thank you. The leak did not occur with OP24 v4.7.7. Do you know what changed in this firmware version?
Do you expect this issue to be fixed in futue releases? Since the quick fix dates back to April, I assume this may be standard behavior when using a VPN together with AdGuard Home. But applying this SSH fix, can’t be the long-term solution.
Did a “dirt” update of 4.9.0-OP24 beta1 so far so good and everything its working without issues, only function where the jury still out is SQM 
Besides that everything good 
What's wrong with him?
If ADG is enabled, DNS resolution will use the DNS servers configured in ADG. This shouldn't be considered a leak, that is an expected behavior.
If there is a policy in the VPN tunnel and it is configured with a 'Specified Domain' list, you can enable ADG, but cannot enable 'AdGuard Home Handle Client Requests' option.
If the behavior you are experiencing does not match this expectation, please PM me the syslog, we try to check first if there is indeed an issue.
Apologize for the trouble. We have discovered this issue in time and located the cause.
The new version of op24-4.9.0 (beta2) is resolved this issue and has been released. Please try to upgrade to this latest firmware and check whether the issue is solved.
Thanks and it’s downloding ….
Edit:
Hi Bruce,
this can’t be correct. When I configure specific devices to use the VPN, as shown in the screenshots, those devices should also use the DNS server configured in the Wireguard config.
With this new default behavior, DNS requests are no longer routed through the VPN, which results in DNS leaks. To prevent this, I would need to use a separate router or implement additional network configurations.
On firmware OP24 4.7.7, this setup worked as expected and did not cause any DNS leakage. Could you please clarify whether this change is intentional or if it is a bug?
Side note: I can no longer attach screenshots. It appears that image attachments now require moderator approval. Is this expected behavior, or is there an issue with my account?
I have this aswell long time user with title edit rights (i believe).
Not sure about this, from how I see it is that adguardhome replaces the dns from dnsmasq it just forwards to adguardhome (stubby).
Logically it makes sense also what Bruce says that you need to configurate the upstream resolver in adguardhome, you could point to a local dns provider from the tunnel.
It however does not make much sense to tunnel full dns over vpn this can break domain resolvement with ddns and such things, if the endpoint was a domain name of course the kill switch could behave contra.
