Nothing in my case, I installed the latest snapshot with kernel 6.6 and the coverage of both bands is damn low, furthermore 256QAM support is missing on 2.4 Ghz, I went back to 4.5.8 beta release 2
Because 256-QAM isn’t a part of the 802.11n standard it’s unlikely to be added anytime soon. But I do know that there’s an option to enable 256-QAM in ImmortalWrt.
When I last tested a GL.iNet firmware the MTK driver was blasting out at whatever power it wanted and I noticed that it doesn’t use regdb at all. So, I guess that’s got something to do with the improved coverage.
My Redmi Note 11 a few meters from the MT6000
OpenWRT with mt76 driver: -30dbm
Firmware 4.5.8 release 2 with MTK driver: -20dbm
This is with 2.4 Ghz, but with 5 Ghz it’s more or less the same thing.
I don’t know if it’s fixed, but with 4.5.7 the transmit power would output with different values depending on where you looked.
I don’t suppose you’ve tried applying the same country and power settings from 4.5.8 R2 into OpenWrt? Since too much power can also have a negative effect.
Yes, I tried to replicate the same settings as the 4.5.8 firmware on the OpenWRT Snapshot but nothing changes.
Even the FritzBox 7590 has better coverage than the MT6000 with mt76 drivers.
In my unscientific observations using WiFi Explorer on an M1 MacBook Air (with Broadcom WiFi chip), with the MacBook in the exact same location in a room diagonally across from the MT6000, and comparing two firmware versions, 4.5.8 r2, and OpenWrt main snapshot freshly compiled last night using testing kernel (6.6) with latest mt76 commits + using 256QAM patches from ImmortalWrt + WED enabled, and the least busy 20 MHz 2.4 GHz and 80 MHz upper 5 GHz channels (regdb stipulates 30 dBm for both with US country code which was set for both devices):
On 4.5.8 r2, signal strength according to WiFi Explorer is consistent with other devices broadcasting at 30 dBm, including an R7800 on OpenWrt 25.03 on both 2.4 GHz and upper 5 GHZ channels, and a Eufy HomeBase on a 2.4 GHz channel. Speed is excellent on both bands, but latency is so-so.
On OpenWrt main snapshot, the 2.4 GHz signal strength is reduced. It was a few percent difference in WiFi Explorer. Nothing too crazy, and nothing that would account for the severely impaired 2.4 GHz performance on the MacBook Air (during a speed test, sometimes it will almost stop sending for seconds at a time, and latency is extremely bad), something also observed in wireless N mode with 256-QAM patches (mac80211 and mt76) applied. 2.4 GHz performance was completely NORMAL on my PC with Intel AX201 and running Ubuntu 22.04, and which is in the same room as the MacBook during testing with both devices.
On OpenWrt main snapshot, the 5 GHz signal strength on the same channel was observed to be significantly reduced, much more-so than at 2.4 GHz as described above. There was an 8-10% reduction in WiFi Explorer. However, this did not affect the speed tests at this distance, as performance was excellent with good latency and speed.
Contrary to what I originally thought, there may be a reduction in signal strength with OpenWrt main snapshot as compared to 4.5.8 r2. However, if it does exist, which is not proven by my WiFi Explorer observation, it probably can’t explain the 2.4 GHz performance problems that only occur with some devices (and may be related to power savings modes).
4 Likes
Where can I find the immortalWRT 256QAM patch?
100% agreed
They should split the forum by product.
Finally got the problematic Laptop to connect on 2.4Ghz. Open-WRT Firmware last night…
OpenWrt SNAPSHOT r25845-7f85104ebb. Connecting like a charm now on 2.4ghz 40Mhz (forced)…
Speedtest on 2.4Ghz with the laptop at the opposite end of the house with several walls in between was over 160Mbps on 2.4Ghz. On 5Ghz (80Mhz) it was getting over 250Mbps in the same location. Happy to have finally got the 2.4Ghz issue resolved (Although it wasn’t really ever an issue for me as I’m totally wired…Just an annoyance more mental than actual use). Not sure why it’s connecting now as I had tried same settings previously (many times) but it’s working like a charm now so I can only assume something got updated in yesterdays Open-WRT firmware that fixed the issue. For anybody having issues on GL.iNet firmware you might want to give a try on the lastest Open-WRT snapshot
OpenWrt SNAPSHOT r25845-7f85104ebb.
1 Like
Unfortunately I didn’t have much time during the weekend. I will put the TUF into a productive environment (Public WiFi network) and then do some benchmarks with the MT6000.
The only difference I noticed so far:
Asus TUF AX6000 OpenWrt 23.05 stable, 20MHz: 150Mbit download steady
MT6000 4.5.7 R5, 20MHz: 100Mbit max
My next test will be: TUF & Asus OpenWRT latest snapshot.
I also have a theory, why the 5GHz WiFi could be freezing on 4.5.6. Maybe its related to WED, which according to OpenWRT is still unstable?
1 Like
I want to share that since I bought the GL-MT6000 I have been struggling with wifi performance.
From the moment 2 wifi clients are sending some data (streaming, social media, …) the internet experience for the end users using WiFi severely downgrades.
I updated to the stable openwrt release (23.05.3), the WiFi issue was still there.
Today I upgraded to the latest openwrt snapshot and it seems that fixed the WiFi speed issue.
I’m currently running: OpenWrt SNAPSHOT r25858-501ef81040
I did spot this commit: mt76: update to Git HEAD (2024-04-03) · openwrt/openwrt@a10a6fb (github.com)
Seems like this improved the situation a lot.
Finally!!! I spent a lot of time trying to improve my setup.
3 Likes
There are several bugs in this version, and since it is no longer maintained, it wouldn’t even be worth focusing on them.
OpenWRT snapshots are much more stable than GL beta versions
4 Likes
Sounds promising! Is there any bigger effort providing an updated version of the official firmware with the latest OpenWRT snapshot?
Unfortunately not. Developers are focusing on resolving bugs using an outdated version of OpenWRT (21.02) due to Mediatek’s proprietary drivers.
If you want to use the latest updates, you will need to use the OpenWRT snapshot.
3 Likes
Looks like they will make both…
But I have no idea why they are continuing to use a totally outdated version that is not receiving security updates.
Is just an waste of resources focusing on 21.02
2 Likes
Although they state OpenWrt 23.05 with kernel 5.15, which is their old buggy fork. Meanwhile OpenWrt snapshots use kernel 6.1 and they’ll soon migrate to 6.6 before releasing OpenWrt 24.x.
Even if GL.iNet were to fork OpenWrt 23.05.3 most of the code would be 7 months old.
1 Like
I have no idea why they prefer to waste resources making their own fork.
They should concentrate their efforts in making fancy user-friendly GUI to home users, while OpenWRT makes the hard job.
They should allocate 1-2 software engineers to make a bridge between OpenWRT and GL-iNet, while the remaining team could focus on user-friendly GUI to their products.
4 Likes
They are using an outdated fork of OpenWRT (21.02) because it is the only one compatible with Mediatek’s proprietary drivers. Version 23 of OpenWRT is not yet compatible with Mediatek drivers and there is no prediction of when this will be.
I agree that doing this is an unnecessary effort because the MT76 driver is already almost stable. Although the issue with 2.4 GHz has not yet been fully resolved, packet loss in the open source version is much lower compared to the GL version.
Updates for the MT76 driver are constantly being released: mt76 updates
If the team of programmers at GL.inet decided to help solve the problem with the open source driver instead of insisting on using Mediatek’s closed version, most of the MT6000’s problems would have already been solved.
1 Like
It really does make no sense what GL is doing. OpenWRT even has a 23.05 stable version since a couple weeks ago for GL-MT6000. Due to many models using the same MTK chipset, there is a steady stream of both bugs and fixes going through the pipeline that GL could benefit from. Instead, they are married to this really hard to understand idea of hoping that MTK will somehow fix all WIFI issues with old drivers on an old and unsupported 21.02 SW base. How does that make any sense?
1 Like
Not quite exactly. They plan to drive on two tracks: