Hi I got a new GL-3000 from GL.iNet and could not find a vanila OpenWrt version support for this, is there any plan to support to this router, or am i missing anything here?
Thank you so much
there's never "any plan", someone with the device on their desk need to do the leg work ...
Thank you, just got excited. Will wait for some to do the magic. Apologies!
Since you have that device already, you can start investigating if it is supportable (and maybe begin the development process) by following this guide:
I am no expert but I have experience with my GL.iNet Opal travel router. If I'm not mistaken the User friendly interface that comes with the router is still running off of OpenWrt as a package. If you're looking for a "Vanilla" version you could try resetting the router thru the Luci interface although I do believe the packages that come with the UI are necessary at this time for the drivers to work properly
https://static.gl-inet.com/www/images/products/datasheet/b3000_datasheet_20240711.pdf is not overly promising, as there is no one working on ipq50xx so far.
It is not.
It appears you are using firmware that is not from the official OpenWrt project.
When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by OpenWrt.org). Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.
You may find that the best options are:
- Install an official version of OpenWrt, if your device is supported (see https://firmware-selector.openwrt.org).
- Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
- Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).
If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.
so that's false advertising ...
they're somewhat honest in the 2nd paragraph https://www.gl-inet.com/support/firmware-versions/
Mmm well that just helped realize something I've been trying to work out so that's interesting..
Anyways I guess I'll stay updated looking around since I was interested in buying one of these routers.
Huh so GL.iNet for some of their routers makes a work around to get openwrt to work. There maybe limitations but that does make things interesting. Theoretically openwrt could work on "unsupported" processors even if there are some caveats
I would not hold my breath for ipq50xx, it's a stripped down (cheapened) SOC with many of its devices not meeting minimum system requirements (RAM) for ath11k based devices and many huge gaps missing in mainline kernel support. At this point in time, it's not that likely that it will get much/ any attention by developers, ipq807x isn't that much more expensive and ipq60xx support isn't that far away either (dragging behind because of QCA's 'phenomenal' opensource attention).
The newer 802.11be based ipq53xx and ipq95xx SOCs are more likely to steal its thunder.
1 Like
The hw vendors are probably the ones doing most of the heavy lifting.
The worst example is the SFT1200, who's stuck with an ancient kernel, with no upgrades nor future openwrt support, ever.
GL-INET interface is built ontop of openwrt luci. On any gl-inet router i am aware of, you can reach the standard luci inteface be simply substituting it on the end url ... /cgi-bin/luci
or thru the gl-inet webui --> advanced ... shoot , i forget the path, but its in there.
The point is aside from the gl-inet webui, which is it own thing built atop the vanila openwrt as you say.
The issue i had with gl-inet firmwares is there outdated. And looking at it now, the download center has change dramatically. They used to uinclude in the release notes, the underlaying version of openwrt, but it seems this is no longer the case
V4.5.18
Overview
This firmware version mainly fixes bugs.
Supported Models
GL-B3000
Improvements
Bug Fixes
Fixed an issue where the device cloned the MAC of the PC on the LAN side and then switched the WAN port to LAN, and the MAC addresses conflicted.
Fixed the issue that the device crashes when the manual MAC clone input is all 0 during relay networking.
Fixed the issue that after 5G WiFi DFS channel detects radar signal evasion, setting DFS channel in the same band will cause wireless not to start.
Fixed the issue that the parental control ruleset does not take effect.
Fixed the issue that MAC address cloning of WAN2 port did not work in some cases.
Fixed an issue where the relay interface MAC address was not synchronized when the MAC address was occasionally switched from the cloned client MAC back to the factory setting.
Fixed the issue that if you modify 2.4G WiFi with 40 bandwidth to relay 20 bandwidth WiFi, and then switch to relay 5G WiFi without disconnecting the relay, 2.4G WiFi bandwidth is still 20.
Fixed the problem of incorrect channel change after restarting with specific bandwidth setting.
Fixed the problem of duplicate configuration prompt after VLAN ID deletion.
Fixed the issue that modifying 5G WiFi encryption and changing wireless mode may cause the MAC to change to 0 and WiFi cannot be searched.
Fixed the issue that after relaying a WiFi with Chinese characters in the SSID, the display is not normal when using the iw dev command.
Fixed the issue that the 5G 144 channel does not have DFS channel identification when the WiFi country code is JP.
Fixed the issue that the old VLAN ID value of WAN2 is not cleared when the device is in Dual WAN mode and the network is restored by pressing the reset button 4S on the device.
Fixed the issue that the relay scanning timeout occurs when the AP is in DFS state.
Fixed the issue that some WiFi with special characters cannot be relayed.
Fixed the issue that the device can not get IPV6 address when switching to AP mode and then switching back to routing mode after IPV6 is enabled.
Fixed the issue that the IPV6 address is not reachable when the device is switched to dual WAN mode and the cable of WAN2 port is switched to WAN1 port.
Fixed the issue that the superior did not configure the VLAN ID, and after setting the VLAN ID value to 1, the device can get the IP address but cannot access the Internet.
Fixed the issue that the device will fail to connect to 2.4G WiFi when relaying data in the known list for the first time, and will automatically switch to other WiFi in the known list.
Fix the issue that the page prompts abnormality when the device opens dual WAN mode and unplugs the WAN1 port cable when configuring the WAN2 port.
Fixed the issue that setting the wireless timer switch and switching the transmit power in the timer task does not take effect after the port number of HTTP is modified.
Fixed the issue that the relay scanning page prompts that the EAP network is not supported to be relayed, but it can be scanned and relayed successfully in the test result.
thou, one could simply check the version like so
cat /etc/os-release
NAME="OpenWrt"
VERSION="SNAPSHOT"
ID="openwrt"
ID_LIKE="lede openwrt"
PRETTY_NAME="OpenWrt SNAPSHOT"
VERSION_ID="snapshot"
HOME_URL="https://openwrt.org/"
BUG_URL="https://bugs.openwrt.org/"
SUPPORT_URL="https://forum.openwrt.org/"
BUILD_ID="r23383-d9210c5ff7"
OPENWRT_BOARD="ath79/generic"
OPENWRT_ARCH="mips_24kc"
OPENWRT_TAINTS="no-all"
OPENWRT_DEVICE_MANUFACTURER="OpenWrt"
OPENWRT_DEVICE_MANUFACTURER_URL="https://openwrt.org/"
OPENWRT_DEVICE_PRODUCT="Generic"
OPENWRT_DEVICE_REVISION="v0"
OPENWRT_RELEASE="OpenWrt SNAPSHOT r23383-d9210c5ff7"
to be clear .. the above output is just a random gl-inet 6416 on my network, not from a GL-B3000
Just to be clear, the following statement is absolutely incorrect:
GL-Inet makes significant modifications to the way that OpenWrt functions. Their builds are "based on OpenWrt" and are as much like the official project as "Maple Flavored Pancake Syrup" is like the genuine pure maple syrup that comes from maple trees.
In some cases, they can use existing supported targets but in others they are using proprietary closed source code for chipsets not supported by OpenWrt or mainline linux. In all cases, though, their modifications are much more than merely a LuCI skin -- they are deep modifications that fundamentally change the way that the firmware works, including the basic syntax of several of the key configuration files. That is why all requests for help using the GL-inet vendor firmware must go to their support channels -- we don't know what has been changed, why, and how it is supposed to work.
This remains true in terms of the "based on OpenWrt" version they are using, although it does depend on the specific device/platform -- some have been forked more recently than others.
Well i can say ...from personal experience, with every gl-inet router I own, I can build a vanilla firmware with no issues, with exception to the mifi as i recall I had some issues with the 3g/4g wifi due to the driver used for the modem. Now i only have a handful of these devices. 6416, X750, mifi and a few other pocket routers. But as a matter of fact the gl-inet firmware download section used to include the vanilla openwrt version the beside the modified gl-inet version. I believe the op was looking for a vanilla version aka without all the bells and whistles included in the gl gui. I simply offered a way in which to check what version of openwrt is being used or aka the "vanila" version.
Edit .. the mifi works fine with latest 23.05.3 version, i just built an image a few days ago for testing a new library. Seems to be running like a champ!
Two things must be clarified here:
- If the models you own are supported by the official OpenWrt project, then yes, of course you can download and build with no issues.
- If the models are not supported by OpenWrt and/or you are downloading from GL-inet's repo and building from there, that is not "vanilla firmware" -- that is still vendor firmware.
That being said, I can assure you that not all GL-inet devices are supported by the official project. It may just so happen that you have supported devices, but it is critical not to generalize unless you have experience with all the GL-inet devices and have downloaded directly from the official OpenWrt repos.
If the firmware comes from any other source, it cannot be guaranteed to be "vanilla," and if it requires additions from GL-inet's repos in order to work, that means that the device is not running "vanilla" OpenWrt. It is only if the firmware is available here (openwrt.org or the official project git repos) can it be considered official/"vanilla".
The firmware selector or table of hardware are the two best places to go to learn about a device's status with the official project. If it doesn't show up, it is not supported. In some cases, unsupported devices are listed, but there are clear indicators of that fact.
you seem to be missing the point. As for functionality of the device/s i ownfor certain .. no modification is necessary for normal device operation while running the vanila openwrt, be it from the gl-inet firmware download section, i image i copile myself from vanila openwrt source, of from the official openwrt valina version., . All openwrt functionallity ..luci or otherwise...drivers ...pkgs ..etc all work as expected. The modifications made to the firmware but gl-inet .. from my experience, is merley cometic, in terms of the underlaying vanila openwrt. I see no real modifiv=cation to the actuall openwrt sources, just additional functionality or abstraction being added to aid in end user experience.
No, I don't think so...
this is not vanilla.
this is only "vanilla" if it comes from the OpenWrt official repos. Is that where you are obtaining the code?
Again, it depends what specific things you're talking about if the firmware comes from another source, and where the packages/drivers are coming from, too.
That may be your experience, but that is not generalizable and I can tell you for certain (from my experience) that there are a lot of changes for some devices that clearly show that their firmware is not the same as official OpenWrt.
lets agree to disagree and move on. If the op want to know what version of vanila openwrt in which their gl-inet router is currently running, they can do so as i suggested. I am of the impression the op, like myself has better things to fill the space used for the bloated gl-inet gui. Don't get me wrong, it certainly has its purpose, its just not for everyone. what the op does with the router or with the information gained is for them to decide. Personally, i would find the version being used and start there. next look at things like the /usr/lib/opkg/info/*.list see what all is included for pkgs, determine what is nessecary for basic operation, build the image, then start adding the packages found in the research of the opkg list of the gl-inet image to regain full functionality without the bloat.
Just out of curiosity, do you consider firmware i build myself, from original, unmodified openwrt sources, to be official vanila firmware? or do you define any firmare not prebuilt by the openwrt bot to be unofficial ?