Based on openwrt 21.02 ?
Rather unacceptable and very peculiar for new hardware and newly-released router. Firmware updates for Gl.iNet routers are already very delayed for existing products, but having a new release this outdated is not right.
2 Likes
Then it would really shock you to know that most chipset bases are design years old.
Also, most other manufacturer’s AX units that base off openwrt, are mostly working on a 4.x kernel. Especially Asus, they have Wifi 7 units working on kernel 4.19
Don’t buy it or make your own router. Problem solved.
Ubiquiti just released a travel router of their own and it only has Wifi 5. Perhaps you should tell them it’s "unacceptable".
2 Likes
Nice attempts at distractions. This is not an Asus or a Ubiquiti forum, if y’all want to shill their products I’m sure they have fora for you.
Fact is the new Beryl 7 (which I was hoping had rectified the USB power issue from the previous version) is running exceptionally outdated software, even compared to the previous Beryl (Beryl AX / MT3000). Which also means it starts life with multiple vulnerabilities which may never be fixed.
1 Like
The problem is that the custom vendor blobs are implemented at a lower kernel version from the manufacturer themselves. The open source versions may have a higher kernel version.
Nobody is trying to shill you anything, what I stated is facts, whether it be gl.inet forum or whatever. You complaining and explaining won't solve the issues you are having, so that's rather pointless. Don't like the router? Don't buy it..
1 Like
Though comming from very early gl-inet routers.
As consumer what pokes my interest is that it comes with a easy ui and OpenWrt.
I know with the era of Flint 1, we were stuck for a extremely long time on OpenWrt 15.5 and basicly I would have thought GL-iNet never again would make these mistakes.
Though wether you like it or not, here we are again.
I learned that it is either because of the lack of stable wireless they rather choose vendor sdks which in long term work more imutable/reliable thats the reason the OpenWrt base is so ancient because it always works, but as I know this is not comparable at all but a mindset, personally I think GL-iNet needs to listen very carefully to this demand, personally its the damage control making them stuck, and personally when I look to the whole Flint 2 situation and the sticky on the download page about the op24 firmware, I see no reason why not to do it... It works very good aslong you keep it on the releases maybe now minus one candidate less because of the APK introduction and wifi-scripts-ucode these deff could pose breakage.
What I get however from the message is a false sense that OpenWrt is bad, it isn't true.
But it is also what is on supply and demand with the chips, and this made them to go with qsdk in more recent routers.
I hope the company learns about their true OpenWrt fans 
Back then it had nothing to do with enterprise level styled routers, it's a total different audience but more of the hobbyist where mistakes where allowed.
I really want to have this low level a bit back, i read some comments here, it doesn't match what this company standed for when I joined this forum , it was always open for things and now I read people need to buy a other router if they disagreed, crazy.
Sure all routers even non branded ones use old OpenWrt bases in their propetairy MTK/QSDK forks, but I bought them purely for OpenWrt with the ui.
Great example:
My first router was the MangoV2, I think that was the way to go, as far as I know it always used recent OpenWrts.
Before I invested in possible the worst routers you can imagine as target for OpenWrt like a bunch of old tp-links 1043nds, and linksys they always had quircks with wifi due to OpenWrts issues with Qualcomm, GL-iNet routers where the first full complete packages which didn't had those issues.
The Flint 2 also proofs this, I have also had some other routers to test like the ax6s but there were still some issues with OpenWrt or that partition layouts got changed it are never fun things, for me this often invites me to cold brick my device because I hate reading the documentation for this change hence the warnings on the sysupgrade page 
If they just step back at:
OpenWrt + nice gui
And then keep OpenWrt recent aslong these possibilities are there, I see no issue, I agree with OP with most of the things.
But it is important to know such ancient kernel doesn't necessary mean you are vulnerable in security GL-iNet can also choose to backport things, I rather trust them than a tp-link firmware
4 Likes
I am more than happy to know what open vulnerability is important for you to solve.
Tailscale management console specifically says there is a vulnerability in the installed version. So thats one very obvious one, which is also something I use. It also seems impossible to upgrade the installed tailscale plugin. This problem also exists on other Gl.Inet routers even with more recent base openwrt
If I had known before buying then I may have reconsidered. But the specifications are not made public, and since other 4.8.x GL firmware are on much newer Openwrt base it would be expected that this would also be.
Just sitting there saying “dont buy it” does not help for people who have already purchased it, or is that something you cannot comprehend? My post may well help others to better decide if they want this product or not, since nowhere else is the actual details made public.
2 Likes
Have you tried to use direct OpenWrt from downloads.openwrt.org? (Releases only have luci)
There is also a other issue with their packages, often they compiled on one of these ancient sdks, or have the packages compiled on the op24 toolchain but they expect to share these packages with such difference in their repo, this can cause package breakage and things which don't work.
1 Like
Partially agree, although one major issue is that somewhere around Openwrt 23 ( I think) lots of changes were made which caused major package (“plugin”) incompatibility. Some package maintainers dropped support completely for older versions. Thus some packages I would like to use on the router will not be available and one of the reasons I use pure OpenWrt on some of my older GL.inet routers.
Additionally, since GL.iNet is marketing the tailscale option, they should also at least ensure that is updated. Not saying the entire system is insecure, however it has to be asked, if they are ignoring 1 thing, how many others are being ignored?
The marketing has become problematic - The inadeqaute power delivery over USB for Beryl AX was never even acknowledged. The 1GB Ram advertised on Slate 7 of which about 70% is used seemingly for the display (which is really one of the most useless additions ever). “New products” advertised with no details many months in advance but sometimes never actually materialise (LWR01) or arrive already outdated, Beryl 7.
Gl.inet could, or should, make a standard openwrt version available, like they have with some of the other routers, but to not have this available at launch, when this product has been advertised for months …. again, not really looking good.
3 Likes
I have tried updating tailscale manually on a different Gl.inet router. It went badly to the point where it needed to be reset. It would possibly be better if they did not modify packages like tailscale and just let them be used directly from openwrt.
1 Like
Interopability can be nice yeah, I have requested this alot with the firewall rules first it was all hidden from lucis firewall purely in iptables, theres still some things though I hope they listen to this request 
For development its much better anyway than reinventing the wheel.
1 Like
Okay, I don't use taliscale. It is not obvious at all to me. And I somehow have the feeling it is not to you as well.
‘There is a vulnerability’. In the Plugin? In the OpenWrt? In the Kernel?
Is the possible vulnerability related to any component in the router? Is it active in the setup or just possible to compile in?
My local scanner mentioned my router as well, with a known CVE over 9. I do not trust blindly. I’ve checked if there is a real issue. See OpenWrt: Updates close security holes in router operating system … Spoiler: the vulnerability is there, in th OpenWrt source, but the part is not compiled in the GL.iNet package.
If the tailscale management system says there is a vulnerability in (the package on the Gl.iNet router connecting in) v1.80.x and it should be updated to at least v1.90.2 then I will trust that the plugin / package should be upgraded. I don’t care or need to know what exactly the vulnerability is, but that is quite a version jump it wants. Which is not possible using the GL.iNet firmware (obviously possible on routers with pure OpenWRT).
Since you are not aware of tailscale and are just guessing, your post comes across as rather unhelpful and dismissive of a valid concern
1 Like
Unhelpful? Okay … Let me explain: The reason I am reading here is, because people tend to ask me questions. I can’t make every error myself, so I’ll try to keep up. And I am also interested in topics that are not direct connected to my setup. If you say I am not helpful, I excuse myself for any trouble I caused.
One issue with OpenSource is, everybody want to use it, but only a few are actually contributing. I don’t use tailscale, which does not mean I don’t ware of it.
I started to pull the tailscale binary from the Beryl 7, and got the information the architecture is aarch64 (named ARM64 at https://pkgs.tailscale.com/stable/#static). I unziped the package and was able to replace the binary. but I have no clue what to do with the systemd folder, since the Beryl7 does not use systemd.
But the well known user @admon was as always one step ahead of me, and provided us all a great solution: GitHub - admonstrator/glinet-tailscale-updater: This script updates the Tailscale installation on GL.iNet routers. .. thank you (admon), again
Now I see 2 solutions:
a. Trust this forum, use the script and having a very good solution for the message on your tailscale admin page.
b. Read the script, understand what it is doing and perform the steps manually, to keep your environment secure.
I’ve tested the script at my Beryl 7, it works. I can’t test if it will connect, because of no account at the other end.
root@GL-MT3600BE:~# /usr/sbin/tailscaled --version
1.92.3-tiny.by.admon.1104
tailscale commit: 9a08e8f1c2021d5c85895e660cf01d8bb1bc9df0
long version: 1.92.3-t9a08e8f1c-tiny.by.admon.1104
go version: go1.25.5
Thats what you get for buying a router that uses open-source firmware, that was built and supported by random people on their own free time as a hobby!! So the fault is yours alone for NOT doing research in advance!
OpenWRT is no different than DDWrt or Freshtomato firmware, that were developed by random people for free, on their own time and its being maintained by random people from all over the world.
If you want better quality product, then buy it from a company that uses closed-sourced software/firmware! Like Cisco or Ubiquiti.
But sure, let’s blame a small company because it took you this long to finally realize that openwrt has issues that may never be fixed.
Quality products cost money, that’s why companies like Asus sell same or similar hardware routers for double the price! Because of the work they put in to their own software/firmware.
Cheers,
Happy Holidays!
Thanks, that makes a huge difference.
However, the question still remains, why is a freshly-released router using very outdated packages, on an even more outdated base, especially if, as your instructions seem to indicate, it would have been fairly simple to update the critical packages before shipping out
Lol, hope your barely-related rant made you feel better. In general the GL.iNet hardware has no quality issues (except possibly USB power on Beryl AX) and no functional issues, they are solid, well performing and cost effective, plus there is a near unlimited option to modify however the user wants.
The only concern I have is that a new top of the line model is released with severely outdated base OpenWRT. Regardless of backports and such, it remains outdated.
Cisco, Asus, Ubiquiti etc have had more than their share of software issues and vulnerabilities so you are just paying more for no real benefit.