I think that they went too fast with the release of this modem, and there is a lack on “beta testers” who actually didn’t test something well.
GL.iNet should take more care of his testers and choose them by a little (and better) precise theory.
Now we have a router which got a veeeery long beta experience, with developers that tried to fix problems…the consequence is that there are still several problems or new ones have been created.
Could you check if with the ethtool command you got the “2500baseT/Full” link modes on your interface?Both WAN and LAN.
Make sure also you got Auto Negotiation on the interface set to “on” when running the ethtool command.
So when 5ghz wifi is set to 160mhz, it states only DFS channel will be used. The router still uses channel 44 for me unless I force a dfs. Then it works.
Having used Tomato, Asus Merlin, DDWRT, OpenWRT as well as proprietary routers, it is shocking that what appears to be a good company, GL.iNet, right now seems clueless to figure this out. And they for sure will not get where they need to be unless either a) MediaTek steps up and ports the closed source drivers to latest OpenWRT or b) GL.iNet goes back to the original strategy of using latest OpenWRT and opensource drivers.
DNS encryption, as an example, is a necessary function. IPv6 is necessary. Having the 2.5 G Ethernet ports is necessary. 4x4 WIFI on both bands is necessary. On some of the 4.5.7 builds, IPv6 does not function. 2.5G ports do not work. It is not possible to use basic functions to monitor your WIFI channels. I would also say security is necessary. It is not a winning strategy for GL.iNet to try to backport security fixes to the OpenWRT 21.02 base as that base is no longer maintained and has not been for nearly a year (May 2023). How is it a good idea to base router security on software that has not been maintained for a year???
The Flint 2 was advertised as running latest OpenWRT 23.05. Yes, it was advertised that way. And advertised as having both a GL.iNet GUI and full OpenWRT functionality. We have a saying “You get what you expect.” If the community accepts less than what GL.iNet committed, that is what you will get. It is not about being mean or nice. It is about GL.iNet doing what they agreed to do when the routers were sold.
I agree. I think the latest Openwrt with open source firmware even outweighs the supposedly fix that the “stable 4.5.7” have. I could honestly sacrifice the 2.4ghz wifi performance rather than dealing with these new caveats.
2.4 GHz, as said by others, is mostly used for IoT (and old legacy) devices because the 2.4 GHz WIFI chips are really cheap. Personally, nearly all my 2.4 GHz IoT devices won’t connect on any router at more than 100 Mbps as they have a single antenna (1 stream).
@admon the people buying a router like the GL-MT6000, which runs OpenWRT, are not the typical Netgear or Linksys customer. If someone wants a basic router that is stable but without many functions, they would buy a Netgear or Linksys. People buy the GL-MT6000 to get the full functionality that OpenWRT provides (and we assumed it would be stable as the MediaTek Filogic 830 chipset is used on many OpenWRT routers).
Just like what Dondi said, I don’t think thats its a big of a thing especially with the real life scenarios. Also we all know that those “theoretical” numbers are simply theoretical and far from from what normal day usage can achieve. Even Asus is doing that.
Just that something is real new, that does not mean that it will run stable, that would be super unrealistic to expect, also this is one of the primary reasons many sdk from vendor firmware use older versions, and now gl also goes that path.
You will be the tester of a bleeding edge device, and i don’t see a difference in other devices.
So for me nobody is at fault here, even if it got released to early for stable adoption by OpenWrt these things can happen if i put myself in their position.
I got a nice example when wifi 6 was brand new, and everyone went on the bandwagon to buy a ax6s or a other similar routers.
It did ran stable for a long time, until recently, it also got range trouble, bridges / lan part hanging and wireless crashing, these might now be fixed.
and soon i gonna migrate my mochabin to a bpi R4 with a wifi 7 module, oh boy… it would not reasonable to expect that it will not introduce issues even when they already make great ads that it can pull 32gbs wifi lol!.
So there is some truth in there wether you want to accept that or not, im only thankful gl-inet keeps working on it
This still is not a big issue for me, the only issue i can think of is something like multi psk being added in a later OpenWrt 23.05 version with wifi-station config nodes.
a older kernel does not mean it is vulnerable, gl-inet can choose to backport patches for vulnerabilities.
since i got the opportunity to compile my own non oem OpenWrt images i can check stability between the 2 since i own two flint 2.
The wifi issues are still present for 2.4ghz, the hanging / crashing with eth_soc are fixed and stable on upstream OpenWrt now.
Agree. 4.5.6 was stable. Yes, the WIFI drivers need some improvement on 4.5.6 but this build generally worked pretty well. GLI needs to revert their decision and base the router on 4.5.6.
Maybe this is like New Coke. 4.5.7 builds make us wish for the old 4.5.6 builds, which were superior in pretty much every way. Come on GL.iNet give us back our 4.5.6 builds!
Believe me, GLI will not be backporting. They are barely just able to get these builds out with their current staffing. Backporting is not happening on 21.02 even in our dreams. That is why a small company like GLI needs to follow 23.05 as the OpenWRT community does the heavy lifting and keeps the base current at no cost to GLI.