TX Power Limitation on Recent GL.iNet MT6000 Firmware (4.8.4+) vs OpenWrt / Older Builds

Router VPN, DNS, Leaks
1

Hello GL.iNet Support Team and community,

I would like to report and discuss what appears to be a significant TX power limitation/regression on recent firmware versions for the GL.iNet GL-MT6000, especially compared with:

  • older firmware behavior,
  • and OpenWrt-based builds.

Device

  • Device: GL.iNet GL-MT6000
  • Chipset: MediaTek MT7986
  • Firmware tested:
    • 4.8.3 official
    • 4.8.4 and newer reports from users
    • OpenWrt-based beta builds

Main Observation

On official GL.iNet firmware:

iwinfo rax0 info

shows:

Tx-Power: 20 dBm

This remains capped at:

  • 20 dBm
  • even with:
    • Country = UK
    • Country = US
    • DFS channels
    • Channel 100
    • HE80 enabled

Example:

rax0 ESSID: "GL-5G"
Channel: 100 (5.500 GHz)
HT Mode: HE80
Tx-Power: 20 dBm

Important Finding

When testing OpenWrt/OpenWrt-based firmware on the same hardware, using US regulatory domain, the router was able to report:

30 dBm

This strongly suggests:

  • the MT6000 hardware itself is capable of higher TX power,
  • and the current limitation is coming from:
    • firmware,
    • MediaTek driver enforcement,
    • SKU/regulatory implementation,
    • or GL.iNet custom txpower handling.

Firmware Analysis

After analyzing the firmware image, several relevant components were identified:

Present in GL.iNet firmware:

/etc/init.d/gl-txpower-init
/etc/wireless/mediatek/mt7986-sku.dat
/etc/wireless/mediatek/mt7986-ax6000.dbdc.b1.dat

There are references to:

CountryCode
SKUenable

which appear to enforce regional TX power policies.

Why This Matters

Many users are reporting that:

  • newer firmware versions feel weaker,
  • Wi-Fi coverage is reduced,
  • signal penetration is worse,
  • throughput at distance dropped,
  • and some users are downgrading back to 4.8.3.

This issue appears especially noticeable on:

  • 5 GHz,
  • DFS channels,
  • mesh/repeater scenarios,
  • and long-distance links.

Questions for GL.iNet / Developers

  1. Was TX power intentionally reduced in newer firmware versions?

  2. Did MediaTek regulatory enforcement change recently?

  3. Is there additional SKU enforcement in 4.8.4+?

  4. Why does OpenWrt report/support higher TX power on the same hardware?

  5. Is iwinfo showing conducted power only, or actual effective EIRP?

  6. Can advanced users disable conservative TX enforcement?

  7. Were there thermal/stability/legal reasons behind these changes?

Additional Notes

  • Testing was done using:

    • Channel 100
    • HE80
    • UK and US regions

  • Despite DFS usage, official firmware remained capped at:

    • 20 dBm reported TX power.

  • OpenWrt builds on identical hardware reported:

    • 30 dBm.

Request

Could the GL.iNet team please clarify:

  • whether this is intentional,
  • whether it is a MediaTek driver limitation,
  • and whether future firmware will restore previous TX behavior?

Many advanced users would appreciate:

  • transparency,
  • optional advanced TX settings,
  • or an explanation of the regulatory/technical limitations involved.

Additional Request for Firmware 4.9

As a final request to the GL.iNet technical team:

Please consider improving or relaxing the current Wi-Fi TX power limitations in the upcoming stable 4.9 firmware for the GL-MT6000.

Many advanced users understand and respect:

  • FCC/CE/ETSI regulatory requirements,
  • thermal limitations,
  • and stability concerns.

However, users also expect the MT6000 flagship hardware to deliver its maximum practical 5 GHz coverage and performance capabilities.

A balanced approach would be highly appreciated, for example:

  • optimized regulatory tuning,
  • improved DFS channel performance,
  • better long-range throughput,
  • optional advanced TX settings for experienced users,
  • or a selectable “Performance Mode” that remains within legal compliance.

Currently, many users feel that newer firmware versions are noticeably more restrictive compared with older firmware or OpenWrt builds.

The MT6000 hardware is clearly capable of stronger wireless performance, and it would be great if firmware 4.9 could better utilize the full potential of the device while still respecting legal regulations and maintaining stability.

Thank you for your excellent hardware and continued firmware development.

Thank you.

2 Likes
2

The glinet team more than likely have the reg database wrong, I have read all the posts on this topic for a while and that is the only conclusion that I can see being the reason.

Is there a way to force a company to follow the rules

Here is the database people can look for their country and what channels are allowed use 20db or 30db, I'm in Canada and some channels are allowed to have 30db.

Look for the 2026 db ( wireless-regdb-2026.03.18.tar.gz ) inside that you will find " db.txt " with power levels per channel

Here is Canada

country CA: DFS-FCC
(2400 - 2483.5 @ 40), (4000 mW)
(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (500 mW), DFS, AUTO-BW
# This range ends at 5725 MHz, but channel 144 extends to 5730 MHz.
# Since 5725 ~ 5730 MHz belongs to the next range which has looser
# requirements, we can extend the range by 5 MHz to make the kernel
# happy and be able to use channel 144.
(5470 - 5730 @ 160), (500 mW), DFS
(5730 - 5850 @ 80), (4000 mW), AUTO-BW
(5850 - 5895 @ 40), (27), AUTO-BW
(5925 - 7125 @ 320), (12), NO-OUTDOOR

1 Like
3

I think you are partially correct about the regulatory database, but after deeper testing and firmware analysis on the GL-MT6000, the situation appears more complex than only a wrong regdb entry.

I tested:

  • Country = US
  • Channel 149 (UNII-3)
  • HE80

According to FCC regulatory database:
(5730 - 5850 @ 80), (30)

So theoretically the router should allow much higher TX power on these channels.

However, official GL.iNet firmware still reports:
Tx-Power: 20 dBm

even on:

  • US region,
  • Channel 149,
  • DFS/non-DFS testing.

Meanwhile, OpenWrt builds on the same hardware were able to report much higher TX limits (up to 30 dBm).

After analyzing the firmware images, it looks like the limitation is not only coming from Linux regdb, but more likely from:

  • MediaTek driver enforcement,
  • SKU tables,
  • EEPROM/calibration handling,
  • and GL.iNet custom wireless scripts such as gl-txpower-init.

So I believe:

  • the hardware itself is capable,
  • the FCC rules allow more on some channels,
  • but the official firmware stack is applying additional conservative limits.

The interesting part is that firmware 4.8.4 appears much more restrictive than 4.8.3, while 4.9 beta seems more optimized again.

So hopefully GL.iNet can clarify whether this is:

  • intentional regulatory behavior,
  • thermal/stability protection,
  • or overly conservative driver tuning.
1 Like