Developers should establish a rule for asking questions. So that they don't have to wonder how the error occurred, whether it was a user error or a developer error. I think it would speed up the work on improving the firmware. If you don't provide information about your configuration in the question, such a question should be deleted.
1 Like
Completely agree with this, in the worst scenario a bug got introduced instead of fixed when the information was incorrect/not shared by configuration, then the fix was supplied on wrong behaviour/configuration.
Yeah, and they should stop supporting older firmwares as well - that's what all manufactures do.
The main issue: The firmware quality isn't yet good enough for that.
But usually, it should be the first question every time some opens a case: Did you upgrade to the newest available version? No? Sorry, we can't help you then.
4 Likes
Im still happy if they would use atlassian or something 
Also for visibility reasons like:
- pinning how to post a bug report, formatting etcetera.
Currently on the forum sure it can work, but you often see marketing getting pinned or some other important firmware updates for specific devices these just belong to the forum.
For supporting older devices i think support is fine, but if they do, the bug reporting must be alot smoother, also their build system and space requirements should be improved i think, some package toolchains are really outdated in the plugin section.
Also one thing i often see happening is a withdrawal of a beta, then there are 2 betas out with same version only compile time is different i think thats wrong personally, they could better append a pre2 after it a little version bump so a dev can see the difference.
And sometimes a firmware binary is posted for a user to test a certain case, but often alot of ppl i also blame myself start using it, which is wrong for testing purposes such things can be better be sent with pm 
1 Like
In devices from other companies, BETA tests last even over a year, and then another half a year is pre. Beta tests of the latest software of my netgear xr500 lasted 2 years. The guy above is right, there is no point in supporting previous builds, since a new one has been released, it needs to be worked on and improved. People still stay on version 4.5.0 and expect this software to be improved by sending descriptions of their problems, which is stupid. The same applies to the op24 build, who needs it? If it really makes sense, the entire GL-MT 6000 software should be switched to OpenWRT 24, but if it is only about satisfying someone who wants to install packages from OpenWRT 24, such a person can use a clean build without problems. Developers should focus on stabilizing the latest software build and on beta software and testing new features. In my opinion, the next versions with new improvements are released too quickly, they should be in the testing phase longer, adding for example some new functions and fixing bugs in each next Beta compilation. You also have to take into account only the voices of people who report specific problems with their specific description, whether it is an update, a clean install, or whether I installed packages from outside GL.inet. Now there is no such information, and problems can be created even by using SQM and there are many who install other packages.
2 Likes
100% agree from my side.
The problem occurs that Flint2 was marketed with the promise that it would come with OpenWrt24 installed by default, not to mention that some features do not work with OpenWRT old firmware. Therefore, we are just waiting for their promise to be fulfilled.
5 Likes
The only problem was with Wifi and in my opinion it has been fixed, it works perfectly for me. If you bought equipment and it does not work as it should, i.e. it has a manufacturing defect or is not as described, you have the right to return it. AAAAA well you will not return it, because for this amount you will not get such good equipment anywhere. Do you want promises fulfilled? and Good firmware? then do not bother programmers with errors resulting from laziness and stupidity. That is all I care about. People from version 4.5.0 make updates while preserving settings or constantly restore settings from the previous firmware and cry that they have errors. Following your line of reasoning, I ask where in the Gl.inet software is the creation or restoration of a backup copy? So why do they provide help to people who restore copies and something does not work for them if it was not a PROMISE.
2 Likes
If you own a Slate Plus (A1300), that was released after Slate AX (AX1800) started shipping, it still does not have 4.6.x firmware, so you have to complain about 4.5!!!
If you buy a brand new Shadow (AR300M16) from the GL iNet store today, which is in-stock, and is a product that is still fully supported and not on the End of Life list, the best you can get is 4.3.18. For actively supported routers, depending on model, their latest firmware versions looks like: 3.2.18, 4.3.18, 4.5.19, 4.6.4,and they are running a beta of 4.7. How is this supportable? How is this usable if you own more then 1 model of their router?
GL iNet committed that all their current supported routers would have 4.6.x by September 2024 in this blog post, which they failed to deliver on:
Preventive Actions to Safeguard GL.iNet Users from BSSID-Based Location Tracking - GL.iNet (gl-inet.com)
GL iNet firmware development and release is a disaster
They need to get their act together! There should be one firmware base that all products are working on, so we can all be reporting the same issues. GL iNet, PLEASE FIX THIS!
5 Likes
therefore the bug reporting system should be transparent. You describe what hardware, what software version, whether it is an update with the settings of the older version preserved or not. In my opinion they should start with this and ignore people who do not provide basic information and those who use external plugins such as SQM
2 Likes
They had bug tracking system that was online and visible. They killed it. I feel that was a big mistake.
[GL.iNet] Close bug tracker notification - Technical Support for Routers - GL.iNet (gl-inet.com)
I think they try their best to bring more and more routers on the same firmware level. Obviously some have older hardware or not sufficient memory and they have to drop some of the functionality. I hope they continue to bring more of them under one code level and add further functionality. So far I haven't seen ANY routers with this much functionality. (I own the SPitz AX 3000 btw)
I think the issue is that the versions have a non-overlapping set of advantages/features. E.g. the non-opn24 version supposedly has slightly better WiFI support due to using the proprietary MediaTek drivers. However, some things simply don't work, e.g. my provider uses PPPoE, but we are supposed to use baby jumbo frames (so that in the end the MTU of the encapsulated frames is 1500). However, setting an MTU > 1500 on the WAN in this way is not supported in the non-opn24 version.
We get in this world of slightly disjoint firmwares because upstream hardware vendors make a mess of upstreaming hardware support. And MediaTek seems like a very good citizen compared to e.g. RockChip (see how long it takes for the support for SoC of the Nanopi R6S to be upstreamed).
Also, I wonder what the security impact of running these old OpenWrt versions is. OpenWrt has ended security support for 21.02 a year and five months ago. Is GL.iNet still updating every package and tracking Linux LTS or is band-aid put in place for just the worst vulnerabilities?
Not gonna lie, It was disappointed in my purchase of one of the latest routers (GL-X3000) and seeing OpenWrt 21.02-SNAPSHOT on it. Would have been nice to see a more updated version. Also, there were many problems with the module when I purchased and only now with latest module and router firmware do I feel I have a functioning router. I'm extremely happy to be able to use T-Mo SIM and have internet where I do so this device has been brilliant! I'd like to see 4.7 become stable and then they can switch to OpenWRT 24. Personally, I don't have a need for 4.7 but I can understand why others would so I'll roll with it. I think I'll just stay on 4.4 release for the foreseeable future since its running just fine. I don't feel that the router is extremely venerable running OpenWRT 21.02 but the hardware in this router should be more than capable of running OpenWRT 24. I think the programmers have recently stepped up their game so I'll be happy to see what happens. I say get the bugs out, stop adding new features for the moment and move forward with updating the OS on the latest routers that are compatible at the very least.
1 Like
Having a bug racker would make the process of fixing bugs more structured. Whenever a question here looks like a bug, then ask the person to fill a bug report. Then for the livetime of the bug you can track it and close it once fixed. Trying to use this forum for finding bugs is a mess.
4 Likes
GL has a bug tracker, just not a public one anymore.
The main issue: Bug trackers don't work with (non-techie) customers. Customers (mostly) don't know how to file a bug and whatever is even wrong. I know that @Bruce classifies bug reports in the forum and then transfers them to GL's internal bug tracker if necessary. That's, in my opinion, the best way to handle it.
Overall, I see a problem here that GL needs to get to grips with fundamentally. I know that they are working on it & I also know that this often takes longer than you think.
From my point of view, it needs:
-
Stable firmware versions that run on many devices without major deviations. "One firmware fits them all"
-
Distance from OpenWrt functionality. Yes, it's all well and good that OpenWrt is the base - but you can't support everything. If package XY is missing in the repos ... then so be it. If you really want to get the full OpenWrt experience, you should use plain OpenWrt AND have the necessary expertise.
-
Provide your own plugins for the GL firmware: Tailscale, ZeroTier and whatever else is often needed should be built in an internal build pipeline of GL and then distributed.
-
Less colorful marketing language that promises things that are not really controllable. Perhaps “AdGuard Home ready” instead of “comes with AdGuard Home”. If there are third-party dependencies in your product ... only advertise it if you are really sure.
-
Distance from support for everything the user can set in luci or SSH: This makes the base system so customized that it takes an incredible amount of time to fix misconfigurations.
-
A better backup/restore system that also works across firmware versions. This would require parsing all parameters and checking whether the target firmware can apply this or whether adjustments may be necessary. Sure, it's a huge effort - but it will help many people, as we know this from other devices. Maybe even an big "reset" button on each router config page to just reset this page (and settings) back to default.
-
Better in-router manuals. Many people don't know the https://docs.gl-inet.com and they ask questions that are already answered multiple times. So a better "Hey, it looks like you want to configure a VPN - do you want to get more information about it?" help is needed. I know that GL is working on that, even with tutorial videos and stuff, which will help a lot.
As already mentioned: GL is developing and so are the support processes. You just have to be a little patient. In the end, it will be important that the router works well for the end customer. And there are more and more people who don't have much technical knowledge.
If you're an expert, none of this will affect you anyway.
These are just my personal 2 cents.
4 Likes
How long do they need? Do they really need more than 4 years to fix this problem?
When the firmware is out of beta, many (most?) users will upgrade while keeping settings. So testing the firmware while keeping settings is important as well as testing it without keeping settings, and I am sure the developers will want to know how process is working both ways. The main purpose of beta is normally to gather this feedback and fix bugs. I will say that some types of feedback are more useful than others, and personally I try and give as much detail as possible and focus on specifics.
1 Like
In case you hadn't read this prior, general recommendations are to wipe settings between major versions (ie 4.6 to 4.7) but it is likely ok to keep settings with minor version upgrades (4.7.0 to 4.7.1). It always best to wipe settings and reconfigure, but I understand that can be a pain. Truly, for beta testing, you should probably start with a clean build for the initial beta load given previously mentioned advice.
1 Like
Agree! See edit above, I actually think you understated it. 
2 Likes