the title says it all!
Hello,
GL firmware does not follow OpenWRT version updates, it has own update plans follow by PM and depends on the market situation, since the GL firmware develop own customize features.
GL firmware with the closed-source has no plans to update to OpenWRT v24.10 recently.
GL firmware with the open-source firmware is already update to v24.10, like the Flint 2 op24 firmware: GL.iNet download center
Thank you.
so does that mean the op24 versions will stay on the wrong kernel version?
So GL FW with OpenWRT v24.10 isn't gonna be updated for 2 more months at least ?
You could synchronize your 4.7.4 version with final build of OpenWRT v24.10 for Flint 2
Not an answer that works. This is not what you guys said when the Flint 2 released. Sorry you just lost me. Tired of waiting and being fed a line of BS just to get us to buy something else
Try not to be entitled, it takes a lot of development to get it to work - hundreds of hours of active development.
It's more just it takes a tonne of work - not to mention, since GL has it's own features, what are you actually looking for with the updated kernel?
I'm sure you could flash vanilla openwrt but you wouldn't do that because there's value in the GL features - which will take a fair amount of time to make compatible and build with a new release of openwrt. Not acceptable, use vanilla openwrt - you'll lose GL features.
Did they say that Flint 2 will get instant 24.10 and then change on that?
Where?
It's more just it takes a tonne of work - not to mention, since GL has it's own features, what are you actually looking for with the updated kernel?
https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.74
where do you want me to begin?
Just any change you're looking for from the kernel would be good
Is it just that it's new and shiny?
I wonder, would op24 be more halted due to APK?
I can see how that complicates things, but i do know it is possible to use opkg again.
The question is more if it is good choice to keep falling back on older things.
Example:
iptables -> nftables
opkg -> apk
APK seems to be more stricter, i got issues when a APK package tries to edit another APK config even on compilation, hopefully that gets fixed on OpenWrt.
the issue is more if you keep software on the older logic you have much more work to do for op24+, back when i wrote java i therefor always wrote interfaces, this way i had abstraction between the api/sdk logic and the actual backend code.
I wish that was that simple with OpenWrt, but it is not
OpenWrt 24.10 uses OPKG only, APK packages are not supported. Only main branch was changed to APK.
Not any change.
V4.7.0-op24
Overview
This version mainly adds some new features and optimises the interface interaction to improve the user experience. This version is developed based on the OpenWrt openwrt-24.10 branch (taken from the 66e76aa9 commit, with kernel version 6.6.63).
So op24 is based on 6.6.63, that's [OpenWrt Wiki] OpenWrt 24.10.0-rc1 - First Release Candidate - 3. December 2024
Woulld you like the rc changelogs?
https://openwrt.org/releases/24.10/notes-24.10.0-rc2
https://openwrt.org/releases/24.10/notes-24.10.0-rc4
https://openwrt.org/releases/24.10/notes-24.10.0-rc5
https://openwrt.org/releases/24.10/notes-24.10.0-rc6
https://openwrt.org/releases/24.10/notes-24.10.0-rc7
If you want me to cherry pick the improvements for the MT6000, MT3000 and MT2500, I will, there's enough improvements in there:
- mac80211: update to version 6.12.6
- mac80211: rt2x00: improvement stability of rt2800 driver
- mt76: update to Git HEAD (2025-01-14) < this is hugely important
- yafut: Fix not found package in imagebuilder
- kmod-nfnetlink-cthelper: Add new package
- hostapd: add SAE support for wifi-station and optimize PSK file creation
- mbedtls: Deactivate ARIA block cipher by default
- mediatek: filogic: Migrate wifi configuration device paths
- dnsmasq: add fix related to DNSSEC verification from upstream
- lldpd: bump version to 1.0.18
- lldpd: fix config for build without LLDP-MED
- hostapd: backport upstream patch to fix setting BSS color
- hostapd: fix processing mbssid config option
- netifd: improve packet steering on ipq40xx (and possibly others)
- wifi-scripts: add macaddr_base wifi-device option
- wifi-scripts: add option to set per-device ifname prefix
- wifi-scripts: allow per-IF mesh basic rate selection
There's lots of improvements, not just kernel and we are currently 11 kernel versions out of sync.
Hello,
I made a mistake about the op24 firmware, sorry. I would like to update the info, the 4.7.0-op24 firmware is the op24.10, kernel 6.6.63, like the Flint2 open-source firmware: GL.iNet download center
If you prefer the op24 version, please try upgrading to the 4.7.0-op24 firmware, this version firmware released from GL still opkg repo.
Hi @bruce, will you update OP24 to the latest OpenWRT v24.10.0 in the coming weeks?
I think they are talking about the full release of OpenWrt, this is still release candidate 2.
But very recently OpenWRT 24.10 got out as full release.
Yes exactly, talking about full release not a candidate release, if upgrading from rc2 to final is a pain for the team, then they probably have things set up wrong..
MT-3000 example:
4.7.0-op24 Beta 2024-12-09 --> 2 months old BETA
4.6.6-op24 Release Candidate 2024-10-14 --> 4 months old RC
These are really really slow release cycles for dev builds..
What's so complicate?
Maybe you should consider going back to open sourcing your custom layer with a restrictive license, so that WE can contribute and YOU are protected from competitors just stealing it.
Due to current political tensions and Hong Kong being China now, that would also prevent any doubt about PRC forced backdoors, current release cycles just do not provide safe, secure and trustable router to US the costumers.
Thank you for listening!
I gonna speak for myself not gl-inet or even knowing what the reason is, that is beyond me.
But my guess is that they have issues with their tooling, if you use the image builder from openwrt usually either one can compile images and the toolchain with packages under the arch and router name, but this is only possible if kernels have atleast minimal changes for multiple routers.
So if they switch between a old kernel with a big gap and maybe also different tooling, they likely have to clean/dirclean and compile everything again or compillation breaks.
Why do i suspect it?, you often see they don't have all plugins or some plugins are broken.
For example i tried to use iperf3 -s
it did nothing after i installed it on op24 flint 2.
Likely it is because they used packages from a old toolchain to save space, that seems to be a second issue.
Maybe they can improve this, or find a way with git tags to change states although it is hard to find a good solution, maybe they should use multiple builders in different folders so recompiling is easier rather than failing, needed to use dirclean etc.
The thing is, if you need to dirclean your compile time can take a much longer time which isn't usefull when generating those for testing.