Hello,
I have a flint 2 GL-MT6000 device with latest firmware 4.11.0 and linux kernel 5.4.238.
The linux kernel 5.4 is out of support, latest version is 5.4.302 (December 2025).
I just wonder to know when it will be added the official support of kernel 6.12.94 that is already available on openwrt 25.12.5.
Software support is really important and one of the main reasons for choosing this device.
Thank you
Alfredo
There is currently no verified release date for moving the stable Flint 2 firmware to Linux 6.12. GL.iNet has released an OpenWrt 25 beta branch for Flint 2 using kernel 6.12.94, discussed in OP25 Firmware for Flint 2 & Beryl AX is out, but it should not be treated as equivalent to the stable 4.11.0 branch.
OpenWrt 25.12.5 and GL.iNet stock firmware are separate builds, so availability upstream does not automatically set the stock-firmware schedule. Also, an older kernel version does not by itself establish that the device is unpatched, since vendors can backport security fixes. For production use, remain on the latest stable GL.iNet firmware unless you are prepared to test beta firmware and recover or downgrade if necessary.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
The linux kernel 5.4 is out of support, latest version is 5.4.302 (December 2025).
Hi,
Unfortunately, MTK has not provided us with a newer version SDK for the MT6000 , so the current closed-source firmware is still based on MTK SDK OP21 .
If you would like to use a newer kernel version, we recommend using the OP25 build:
Thank you for your reply. Is there any way to put pressure on MTK? Also, could you use the open source implementation in your build? Essentially, it’s a GUI on top of OpenWRT, isn’t it?
The linked OP25 build is the current open-source-based alternative for Flint 2 with the newer 6.12 kernel. Replacing the MTK SDK base in the stable branch is more involved than placing the GL.iNet GUI over vanilla OpenWrt: the GUI relies on GL.iNet backend services and packages, while Wi-Fi drivers, hardware acceleration, upgrade handling, and other model-specific functions must also be integrated and validated.
Only GL.iNet staff can comment on discussions with MTK or future firmware plans, and the current staff reply does not establish a newer SDK or a date for migrating the stable branch. If you test OP25, back up your configuration first and treat it as a separate branch rather than an in-place kernel update to the current SDK firmware.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
The link we provided earlier is for firmware built with open-source code + the GL SDK (GUI) .
Excellent. Is it based on version 4.9.1? Is there a way to switch from the closed source version to openwrt without deleting the configuration? Are you planning to switch to openwrt? I’ve read this bit, but I think it’s been like that for several years now.
We will continue to address bugs in the open-source version and will make it the main line if it eventually outperforms the closed-source driver.
The currently published Flint 2 OP25 branch is identified separately as v4.9.1-op25; verify the complete build number shown beside the download, because it is not the same firmware branch as standard v4.9.1 or v4.11.0.
When switching between the MTK SDK branch and OP25, use a clean installation without retaining settings. Their network and wireless configurations are not fully compatible, so restoring a complete configuration backup may also reintroduce incompatible settings. Save a backup for reference, then configure the OP25 build manually. GL.iNet has not confirmed that OP25 will replace the SDK branch or provided a schedule; the quoted statement describes a conditional goal rather than a committed migration plan.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
The GL GUI and feature set is 4.9.1, the underlying base is OP25.X for the OpenWrt 25
The MTK SDK version has a Base of OP21.x
These differences have major working differences and so keeping settings generally break many features, best to always reset between major revisions or version changes.
Have been on OP25 since release without issue.
NB. Just because the OP21 kernel is out of support, Security patches that are relevant can still be applied by GL (which happens a lot in the corporate world were SDK and drivers are not compiled for newer versions)
Are you sure about that? If the official linux community doesn’t backport them, will a private company do so? Do you have any sources?
They have said on many threads that critical CVEs are addressed by themselves, most are user escalation exploits and are not relevant as you are already root, and would already need local access. Looks at the threads with CVE numbers
OK, if you’ve got any references. It’s closed source software, so we’ll just have to trust it.
Yeah, They do a good job of addressing CVEs brought up in the forum to be fair, its never easy and they are usually not as simple as the title suggests.
If you are more worried about this more than features, the OP24 and OP25 builds are much more up to date. get future features slower, but nothing you cant do via Luci
Open source code is forked and modified by many large corporations for their own use.
There is often no requirement or desire to attempt to sync those changes back to the parent.
Just because one team considers a branch eol does not prevent others to continue to work on it in their own fork.
MediaTek and gl-inet developers are professional developers.
There is no basis for claim that the code offered in parent open source projects is of higher quality than the code produced in forks or closed source projects.
Many parent open source projects want corporations to offer more of their employees time to assist with maintaining the parent they forked from. High paid experts is a desired resource for open source projects.
Obtaining up-to-date open source code of those modifications from corporations can sometimes seem harder than one would like. Sometimes the modification of behaviour occurs within closed source binary blobs where there is no obligation to show source code.
Many security flaws found are within code that does not apply to a router. Just because Linux has a problem does not mean every use case of Linux is effected by that problem.
Oh also often modifications are not always accepted by the parent open source project.
Eg the way the closed source MTK driver appears to interact with openwrt is non standard. Openwrt was modified by MediaTek to suit their driver. Openwrt likely would not accept that change which was done to suit only MediaTek.
MediaTek closed source driver works the way MediaTek wants it to work, not how openwrt want it to work. MediaTek likely have all kinds of software environments beyond openwrt where their hardware needs to work.
The two projects have different incompatible goals hence direct syncing the code bases is not desired from either side.
Actually, the GPL licence requires that any modifications used in code released to the public must be published. There is a significant difference between free software and open source software.
You’ve misunderstood what I wrote. I said that you have to trust closed source code, whereas open source code can be verified.
Many parent open source projects want corporations to offer more of their employees time to assist with maintaining the parent they forked from. High paid experts is a desired resource for open source projects.
Many companies use open source projects to reduce development costs, not because they believe in its values.
Closed source code, i.e. binary blobs, is not part of the kernel, so it simply has to comply with the interface, nothing more. Openwrt is not responsible for the linux kernel, it is not its problem.