In this case for the AXT1800 but I guess all related models can be upgraded.
I don't know what goes on under the hood with the GL-iNet GUI vis a vis the underlying OpenWRT. It surprises me that they expose Luci at all. There are clearly some things that can be done with packages available with OpenWRT and can be upgraded with less risk of breaking things.
But I suspect it is really complicated to change the underlying OpenWrt and develop and test an associated GUI. It seems like there would be a need to develop a middleware in the middle. Not sure that exists.
And why 24.10.4 and not 24.10.5? Also, 25.12.1.2? I guess we are at 25.12.2 now.
1 Like
TBH I didn’t even check what’s the latest stable, just the minimum requirements for VLESS setup. So I guess everything newer than 24.10.4 is fine.
The following comment is based on pure speculation. I know nothing of the internal functioning of either the GL-iNet GUI or OpenWRT.
It looks like the GL-iNet GUI is just an OpenWRT plugin. If there is middleware, then it is part of the GL GUI’s code. I’m sure that most OpenWRT upgrades don’t change most of the OpenWRT APIs and function interfaces. And I’m also sure that the GL-iNet developers have extensive regression tests for all of the interfaces they use. Between the regression tests and the OpenWRT release notes I assume the GL-iNet developers have a good handle on the changes needed - whether that be in that middleware layer or in the functional code.
That being said, GL-iNet supports a large number of products so the development staff is probably spread pretty thin. It must take a long time for a new release of OpenWRT to get incorporated across the product line.
I assume, too, that if OpenWRT were to change the structure, location, or use of of its config files then chaos would ensue in GL-iNet development, and incorporation of that release would take a very long time.
My understating is the primary reasons the OpenWRT versions are the versions they are is that these are the versions that ship with the SoC vendors SDK. The chips inside the devices often (but not always see below) require closed source drivers to function. These drivers are built and tested against specific OpenWRT/ Kernel versions that the chip vendors supply. Deviating from this would put the support of the modifications on GL and any future new versions would be additional work and overhead to support so it makes sense for everyone to use the versions from the vendor where possible to simplify this process.
For some models (Flint 2 for example), usually using Mediatek SoC, these can work with open source drivers from the community and you will find there are newer OpenWRT versions available as a different firmware or you can install regular OpenWRT and lose the GL UI. For some of these OpenWRT 25 is already in the works.
Overall if you have a need for specific OpenWRT version it makes more sense really to research a compatible device with the hardware you need that supports vanilla OpenWRT itself and use that as you will always be lagging behind and chasing for updates otherwise. For most people though they don’t need this and would get no real benefit from a newer openwrt version.
2 Likes
There’s a 25.12.1 build for the AXT1800 mentioned on the official wiki, most likely upgrading openwrt version for the firmware requires reconfiguration and testing so it takes time and efforts. I don’t have a spare router to test this properly and I don’t want to loose glinet web interface on the current router I own.
25.12.1 had a regression in the mt76 driver that introduced high latency. Replaced now with 25.12.2.
Maybe it would be fair to rephrase this request with “upgrade to the latest stable OpenWRT and keep updates coming”.
Hi,
The AXT1800 currently uses a closed-source SDK provided by Qualcomm, and its OpenWRT version is only available on 23.05.
We will need to wait for Qualcomm to release a new SDK with an updated OpenWRT version before we can provide it.
If you want to use the latest version of OpenWRT, we recommend using vanilla OpenWRT.
You can download it here: