Are there beta testers for the MT6000 here? Never met some.
I bought the router knowing that Iād eventually install an official OpenWrt build onto it, but I didnāt think that Iād be doing that within 24 hours of me receiving the router due to bugs in the stock firmware.
- WiFi crashes (resolved in a later firmware)
- Some devices perform poorly when using 5GHz (still an issue)
- Mediocre 2.4GHz range (still an issue)
- The router comes preconfigured with some outdated settings, which is why you see a warning about legacy rules on this screen and a message about ānetwork ifname configuration migrationā when you view your network interfaces for the first time (still an issue)
- Thereās some seriously outdated packages e.g. nginx and Tor (still an issue)
- Youāre unable to use ddns-scripts-cloudflare because they copied and modified scripts from ddns-scripts and put them into their closed source gl-sdk4-ddns package (still an issue and breaks the terms of the GPL v2 license)
Apart from the mediocre 2.4GHz range all of these issues are resolved by using OpenWrt snapshots. So technically GL.iNet should eventually be able to supply a stable firmware.
At some point I might open my Flint 2 and attach different antennas for the 2.4GHz radio, just to see if the antennas are to blame. Although the original Flint uses similar looking antennas and I donāt think that has any issues with 2.4GHz 
4 Likes
This does not sound like the real fix for me because the issues are heavier when 160 MHz is enabled. But 160 MHz is not less than 160 MHz. So why should it fix this?
The 160MHz issue that youāre currently experiencing with 4.5.5 is unique to the GL.iNet firmware. And I know that because Iām using 160MHz (channel 120) via an AX210 and Iāve used more than a dozen OpenWrt snapshot builds without any issues.
The āreal fixā that gabec24249 is on about there is with regards to 802.11ax (5GHz only) underperforming for some devices (mainly Apple devices and some phones). And this is still an issue in the GL.iNet firmware.
I find it hard to believe that gabec24249 was a beta tester for GL.iNet though, since heās been banned from here and the OpenWrt forums for insulting people and then evading bans 
4 Likes
It happens in 4.5.4 as well - so it seems more like a general driver problem than an OS problem. Which does not mean it might be fixed in some OpenWrt snapshots.
Lovely. 
maybe you are right, but on the other hand if they donāt take critism seriously then why they bother writing a 2023 feature log, yes from time to time i also noticed silence and almost thought they wonāt bother too but that still does not explain why they would bother writing a feature list, some stuff also includes things spoken in prior betas.
on discord they did responded to me for various issues iāve reported, but never got feedback if it was fixed, so maybe you are on something here, but time will know 
they did however noted my vlan ghosting issue with the UI in that feature thread so iām 50/50 here.
iād still call it wrong marketing, I got 2 versions of tp-link 1043nd V2 and V3 both had wifi issues from that time it never got fixed too, I had a Linksys 6350 v3 also had issues with the DSA switching which was broken, and then I also had a Mochabin with a mvbu switch which could sent DSA vlan over wan as the driver had issues.
tinkering is kinda what you can expect from open source things it can change really fast but can also break, this is not a excuse for just GL-iNetā¦ however if you mean that the bug is long existing and multiple times reported I wonāt disagree with you I also see that happen sometimes and it gives beta testers a bad name when they care to really help, for me itās also a reason to consider if I want to do a other beta test in the future or not.
I still think the device is great once OpenWrt is matured 
but alot has to change to the OEM firmware if I want to use it for my purposes my topology is too advanced.
2 Likes
Well the mt76 driver that GL.iNet uses isnāt a 1:1 copy, so thatās a factor. And the OpenWrt snapshots do have a lot of fixes applied elsewhere too. But like Iāve said, Iāve been using 160MHz and updating the firmware every 4-5 days and for me itās rock solid and fast.
Honestly, I think GL.iNet should just create a new firmware thatās based on a newer snapshot build and then merge in their UI/package changes. I think thatād fix most of the issues.
But you was wrong, since you originally claimed that it fixed all WiFi issues. And you was told multiple times why it wouldnāt work for 2.4GHz, yet you kept trying to tell people like myself that weāre wrong. And only now do you admit that the patches only apply to 5GHz.
And that 5GHz issue only applies to certain devices (e.g. Apple phones) that donāt know how to handle 160MHz correctly. But all of my devices do, which is why myself and others didnāt see the issue on the GL-MT6000.
And I find that hard to believe because you were banned 2 or 3 times in a single day from the OpenWrt forums for insulting him in the OpenWrt birthday thread.
At this point youāre just trolling by creating accounts and posting nonsense, since the 5GHz issue has already been patched.
5 Likes
I would to lock this post. Conflict things, I donāt like.
How many accounts have we already counted of this annoying bastard?
4 here, right?
Which openwrt snapshot is for you the most stable and fastest regarding the WiFi speed?
All of the snapshots have been good for me since I donāt have any problematic 5GHz devices. However, if you do then the issue was fixed in 80e4e2285f.
I know that r24793-e691e2b302 was a good snapshot and r24801-b7f9742da8 was a bad one. But the issue with r24801 was quickly resolved, so the latest snapshot (at the time of writing) should be safe to use.
You should follow this guide to set the correct country code for both radios (mixing them can cause issues), enable hardware acceleration and WED.
3 Likes