Your attitude here will not endear you to others. Try to exploit any of these and report back your findings if you are certain. I am sure a few there have public exploits available you can copy and test with. Also, report back whether they are remote, local, priv esc, and what those get you. We will all be waiting.
4 Likes
I don't care. You will be treated how you treat others. You are endlessly arguing about stupid things, not listening, and wasting my time. I am not here to be your friend when you keep acting like tedious know-it-alls and shills as if everything is perfect with GL-iNet's severely outdated firmware, and acting as if I am stupid for asking GL-iNet to stay on top of LTS kernel updates for their customer's sakes.
By the way, I figured out why GL-iNet uses a dead, 700 day old kernel from March 2023:
It's... even worse than just a dead kernel... it's... because GL-iNet Flint 2 uses a dead, 700 day old OpenWrt release which died in May 2023:
https://openwrt.org/docs/guide-developer/security#support_status
OpenWrt has this to say about using OpenWrt 21 and other dead (abandoned/zero maintenance/no security updates) releases:
"Only supported OpenWrt releases are considered safe. Any use of unsupported versions is strongly discouraged due to multiple, severe, well-known, actively exploited security vulnerabilities in the kernel, third-party applications (OpenWrt packages), and 802.11 (WiFi) protocols."
And: "End of life means that we will not provide any updates even for severe security problems. Please update to more recent versions."
I guarantee you that GL-iNet is not monitoring the commits in the upstream repos (OpenWrt, the kernel, all OpenWrt packages) and maintaining and backporting the security-related code changes for OpenWrt, the kernel, the 4000+ different OpenWrt application packages, etc. They are shipping a dead version of OpenWrt -- and that's why the kernel is so old and dead. Because it's what originally shipped with the dead version of OpenWrt. It's as simple as that! And it's a more severe problem than I thought. It's not just an old kernel. It's a vulnerable version of OpenWrt and its packages.
If GL-iNet's op24 test release contained the closed-source Mediatek WiFi driver, I would honestly install the op24 snapshot test branch right away. Sadly I won't be able to use that until the open source WiFi driver becomes stable. People on this forum are still reporting lots of randomly high latency spikes and WiFi becoming slow after less than 3 days of uptime on the Flint 2 with op24, so I can't rely on op24 until the open driver is stable. Those problems are mentioned on the firmware download page by GL-iNet too:
https://dl.gl-inet.com/router/mt6000/open
Due to certain performance and compatibility issues with the open-source drivers for the model, firmware version 4.6.0 will utilize the MTK SDK to ensure a better user experience. If these issues are resolved in the future, we will revert to the Native OpenWrt version with the open-source driver. For customers preferring the open-source driver, we will provide a synchronized Native OpenWrt version labeled 4.x.x-opxx, based on the OpenWrt main branch with kernel version 6.6.x. The MTK SDK will be used for their 4.x version. 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.
If the closed-source driver can run on op24, then I'd love to see an official GL-iNet op24 release with the closed-source Mediatek drivers, @bruce. Is it possible that you can release op24-closedsource too? An op24 snapshot with official Mediatek drivers would be a great thing while we wait for a better op24 open release...
Edit: Actually... The quoted paragraph is really confusing. Is it saying that op24 already uses the closed-source Mediatek SDK after v4.6.0? But it simultaneously says "for people preferring the open-source driver we will provide 4.x.x-opxx". I really don't know what it's trying to say. Does your op24 release already use the closed-source driver or not? That would be great. I'm gonna upgrade immediately if that's the case.
PS: If anyone installs op24, you must manually do this patch for a bug in 4.7.0-op24: [4.7.0-op24] Known bugs - #17 by PanWise
Edit: Sadly, people are still reporting the WiFi signal dying in 4.7.0-op24. Seems it's not a usable option then. [4.7.0-op24] Known bugs - #57 by raphamotta and [4.7.0-op24] Known bugs - #36 by pupeto
Hopefully this mess will be resolved in a few months and we'll be able to use op24. I can see that GL-iNet is actively working on making the op24 branch usable. So at least I can look forward to that, hopefully early next year. 
1 Like
Welcome to my ignore list. Best of luck with your issues.
1 Like
There is no ignore list on this forum. It's called Discourse and it lacks that feature. I also don't need your "help" (your endless, pointless arguing for the past dozen posts here). I am trying to reach the developers about a technical subject, not waste time arguing about whether 700 day old kernels is in fact "a great thing".
Now I know why the kernel is extremely old - it's because GL-iNet uses a dead, unsafe, ancient version of OpenWrt. But at least they're gradually working on making op24 their new, stable version when they've solved various bugs (such as the WiFi issues).
They're planning on making op24 their new stable firmware. There was a release candidate in October - but it was too buggy, so it's been pushed back to Beta status. But firmware development is clearly ongoing, so I look forward to updating when op24 has become more stable. Hopefully early next year.
Have a great day and a happy new year. 
Edit for Renato below: You unfortunately still don't understand what has been said in the thread. I am not even going to dignify your latest exhausting rant with an answer. It's just more of the same circus... 
1 Like
Once again you are supposing that GL-iNet is just using a plain OpenWRT and plain Kernel. This is an wrong assumption.
Their Firmware (which include the OpenWRT and Kernel) are maintained and they are receiving security updates frequently, as you can see HERE.
I already gave you some examples, but let me show once again:
The 1st CVE that you listed is about a BLUETOOTH module, but you can ignore that issue because GL-iNet products are NOT USING that Bluetooth Module!
Once again: what happens when you have a LTS Kernel + a proprietary module? It's not the same LTS Kernel anymore. It's a custom one.
So, ONCE AGAIN: do you have any bug that is present in your product that need any particular patch not yet applied?
For anyone wanting to ignore someone, just click on their username, then in the upper right corner, second option down, you can mark that user muted or ignored.
3 Likes
Muting someone just disables notifications. You still see everything. Grow up.
2 Likes
Chimpans, do you happen to see any more recent MTK-versions?
You appear to be aware of MTK SDK with a more recent kernel. Sadly the MTK SDK is closed source, so how would GL-inet go about updating that? I honestly believe you should be bugging MediaTek. And while you're at it: Qualcomm with their QSDK.
Those 2 are why firmwares based on them are stuck on old versions. Ideally both MediaTek and Qualcomm would make it so their chips would just be supported in mainline kernels, so those whole "MTK SDK" and "QSDK" are not needed. Sadly they do not seem to want to do, so thanks to them this mess exists. There is NO point complaining here because GL-iNet does all they can do: Supply firmware based on the latest MTK SDK (which indeed uses an old kernel and OpenWRT) and ALSO based on stock OpenWRT (Sadly the open source drivers still are not mature enough!). Besides that they are pushing needed patches into stock OpenWRT!
There's not many router suppliers doing all that! Unless you can provide proof there is a more recent MTK SDK (kernel) for the chipset in the MT6000, may I ask you to start complaining towards MediaTek instead of GL-iNet?
I'm fairly sure if GL-iNet could, they would stick on more recent versions, but that requires a more recent MTK SDK, which GL-iNet does not make. So what do you believe this topic will do? I can tell you: Nothing at best. Demotivate and waste time of people at worst.
3 Likes
Jesus Christ, why do Linux and OpenSource people always have to react so fanatically. We're talking about a kernel here. There is no (!) reason to insult each other.
Anyone who doesn't understand this is welcome to take a short break to calm their head.
Once again: We're talking about a kernel. This is one of the most boring topics ever to verbally attack each other. This is not the Linux kernel mailing list.
12 Likes
Hello,
We cannot release a op24 firmware with closed-source, since the closed-source is driven by MT and SDK is also provided by MT.
If we rashly transplant the op23 driver to op24, it probably has a lot of risks and compatibility issues.
Although op23 / kernel5.4 may looks outdated, but please feel safety of using the GL router, if possible you can test our firmware/system in any way. If you have risks to report to us, we are appreciating.
3 Likes
Something that maybe needs to be raised here is that the only reason that there's a way to figure out exactly what comprises the OS for this device is that we can see inside of it. We have total root access. This is not the case for most of the commonly used CPE devices deployed for cellular data applications. For example, we have really no way of knowing how old various components in Inseego, Cradlepoint, HTC, or any of the other locked down, carrier specific CPE devices they hand out.
It would be interesting if any compromises that are known for the Kernel version being run can actually be pulled off. That would prove the point that the Kernel in fact isn't tightened up as GL seems to say it is.
1 Like
Though, in most situations it is very low this can be happen, because the firewall already blocks all inbound by default, and only allows inbound when a local device started the communication first on the same line, it must be likely done with a local scope to succeed.
it will be a handfull of vulnerabilities lower, given if the appliances often lock down services like ssh and telnet, and there is no vulnerable wan scope, though you are correct it is using a rooted system on gl devices but anyone with sense would not open the router on wan with the firewall disabled and or use root user or consider disabling ssh on lan 
also alot of home routers besides GL-iNet also run on older kernels with SDKs even some isp appliances older than OpenWrt chaos calmer, the issue is more that those chip vendors responsible for it don't want to take time to kernel bump, on one hand i think they do it for stability on the other hand it is not good for security and the visibility of it.
Sure it is on vendors themselves to decide to backport certain things, so alot could have been patched, doesn't mean everything can be patched this counts for all brands.
Actually it is OpenWrt themselves doing the heavy lifting, and when you notice on their snapshots sometimes very ugly bugs/regressions can appear when bumping kernels, like: having vlans sending reversed on the mvbu platform some time ago, this means just using a higher kernel doesn't mean it is secure when you don't know about possible dangerous symptoms it can have due to regressions.
Its never good to sent vlans towards the isp
^ this is why they luckily use this as snapshots, changing kernels isn't that easy as OP seem to suggest, and as far the bumping goes it gets done in really small increments like 6.??, where the last ? already could cause adverse effects, it costs alot of time and testing especially on all platforms to ensure the code works around the kernel.
So when you think about this in retroperspective, it makes sense vendor firmwares stay on a ancient kernel because that works for them and doesn't smear the brands using it, plus alot can be solved by backporting and patching security problems.
Is it a full bulletproof solution?, no, it is still a visibility issue on security, but in fairness mtk sdk is still some what recent compared to other sdks, qualcomm is even worse, and some isp modems had a version of OpenWrt 12.09 2013
the drivers are propetairy, only baked in for sdks, openwrt uses a open source offshoot driver which interpretes most of what the sdk driver can do and is called mt76 for mediatek and the maintainer has close involvement with mediatek, qualcomm is even more complicated in support reasons, they use something called ath as driver in no way it can support things like NSS offloading and in alot of situations you can have strange symptoms.
it is purely for this reason why OpenWrt depends mostly on open source drivers for the higher kernels, and why SDKs are very slow in adapting, the better solution would be to not to make it propetairy at all
@xize11 Yeah, it would make the most sense if Mediatek instead became open-source and worked on the open driver. NVIDIA, Intel and AMD already do that on the graphics driver front and it's working great, they get a ton of extra developers for free and everyone's experience becomes better. You are also right that the WAN firewall protects us against a lot of the exploits. And you're right that LTS kernels can sometimes break existing kernel functionality, but you are really exaggerating the risks. 
They already have a lot of testing before releasing any kernel updates (they test on a lot of architectures). But sometimes issues can slip through, yeah. New LTS kernels come out pretty fast when something like that happens.
@n2qew I agree completely. The fact that these routers are open and give us insight to their internals is definitely infinitely better than running some old ASUS router which hasn't got a single update since 2012 for example.
1 Like
Hi Bruce, I appreciate you taking the time to reply!
It is true that you are patching exploits that are found (like you did in August). So I agree that even though the situation of using dead kernel + dead OpenWrt is not perfect, it's better than "it's 700 days old and nothing has been patched at all".
And yes, I agree with you that the closed-source driver should not be the only driver in the op24 branch, but I was suggesting an extra branch "op24-closedsource" where we can test op24 snapshot with the closed source driver. Existing separately from the normal, open-source "op24".
This possibility depends on whether the Mediatek SDK can be compiled on the kernel that op24 uses, of course. But if it can be done, then I'd love to try using it until the open-source driver becomes stable.
Right now, the thing stopping me from installing "op24" is that people are still saying that WiFi becomes weak, slow, and stops working after some days when using the open-source driver. Examples here from the latest 4.7.0-op24:
I really hope the issue is solved sometime this year, so we can all move on to fresh, maintained versions of OpenWrt.
This option doesn't exist.
That driver is a CLOSED SOURCE, compiled by MediaTek SDK for op23.
You cannot put a tyre from a scooter in a minivan!
So try also yourself!
My internet is 500/70Mbps and I'm not experiencing any slowdowns.
The uptime is 11 days:
If would you like an improvement, TEST IT and REPORT the issues.
Please calm down, Renato. No need to be so belligerent all the time. It's a new year. Try to start it off with happiness.
Linux kernel modules (kmod) are often two parts: Closed-source part, and the "kmod" glue part. The glue can be compiled for any kernel as long as the kernel header development files aren't too different. The purpose of that structure is to allow various closed-source drivers to be built for whatever kernel version a vendor uses.
Whether Mediatek follows those best practices or not is up to them, but I already saw that GL-iNet compiles their own kernel. They are NOT being given a pre-compiled kernel by Mediatek:
# uname -a
Linux GL-MT6000 5.4.238 #0 SMP Thu Dec 5 01:20:08 2024 aarch64 GNU/Linux
This, along with Bruce's reply above hinting that compiling the Mediatek SDK for the 6.x kernel is possible (but that he doesn't know if it will be stable), means that we should at least ask for the possibility of such a temporary workaround branch. If it's possible (as he indicates that it may be), then I'd happily try it just to see what happens. And if Mediatek happens to be too poorly organized to have a proper kmod structure for their driver, and it's impossible to use it on another kernel version, then alright, so be it.
Regarding WiFi slowdowns: Dozens of people have reported the same issues, with big latency spikes and WiFi slowdowns with the latest op24 (4.7.0-op24), requiring restarts of the router, and they have already shown that the problem does not happen with the closed-source drivers (4.7.0). So unless there's a big change in what people report about the reliability of the open drivers, I'm not so tempted to go through the work of reinstalling and reconfiguring everything yet.
There's links to two of the newest WiFi problem reports at the bottom of this post (with speed graphs showing the problem):
There's also been tons of talk about the open source WiFi problem (hundreds of posts) in prior releases, which is why the op24 "release candidate" was demoted to "beta" again instead of becoming the new stable release (which was the original plan).
Since those problems are still being demonstrated with the latest 4.7.0-op24 release, I am definitely careful about potentially wasting a whole day reinstalling the router with that firmware, and then reinstalling it again with the closed-source driver if the same problem ruins my own WiFi.
But I'll be watching the new releases with interest to see when people finally report that it's fixed.
Their official answer:
We cannot release a op24 firmware with closed-source, since the closed-source is driven by MT and SDK is also provided by MT.
And also:
Although op23 / kernel5.4 may looks outdated, but please feel safety of using the GL router, if possible you can test our firmware/system in any way. If you have risks to report to us, we are appreciating.
So, once again:
-
List the REAL issues that you have;
-
If you would like to have a newer Kernel and a newer OpenWRT, it's already available. Try it and help reporting the issues.
1 Like
You dishonestly cut away the parts where Bruce indicates that it may be doable. Great. Nice to see that you are still dishonest and aggressive. Happy new 2025, dude!
Here is:
We cannot release a op24 firmware with closed-source, since the closed-source is driven by MT and SDK is also provided by MT.
If we rashly transplant the op23 driver to op24, it probably has a lot of risks and compatibility issues
So, once again:
-
List the REAL issues that you have;
-
If you would like to have a newer Kernel and a newer OpenWRT, it's already available. Try it and help reporting the issues.
1 Like
I've already explained every reason in detail. It is a shame that you are still choosing aggressive toxicity instead of listening. Never giving you a reply again.
