I have an additional iot subnet on my Flint 2 and pass it to an AP. I run the three subnets as vlans over a trunk line. The AP is not in any mode, I just used the LAN port on it and setup each interface as a static IP attached to the corrsponding VLANS, turned off DHCP and firewall on the AP, so the main router handles all the L3. Works fine. I run the iot network restricted from the internet and itself with a few rules added to allow for DHCP, DNS, SNTP to the main router and a few devices can access a company IP for firmware updates.
I’ve just reflashed V4.8.3 without retaining settings as I’ve lost signal to camera.
Have reset country code to GB from DE, but interestingly, ChatGPT says regarding transmission power:
“UK limit = 200 mW = 23 dBm
On Flint 2 + firmware 4.8.3:
-
MediaTek driver caps TX power ≈ 20 dBm
-
Ignores higher values in many cases
-
This is normal behaviour”
Your router is behaving normally -
20 dBm on this firmware = expected limit
-
Changing DE → GB was still the right fix
Presumably this is why it’s 20dBm and not 23dBm:
“Router has 3dBm antenna gain programmed in calibration data… it is lawful requirement to discount antenna gain and limit signal (cf 5GHz where radio power is limited in next line)”
My hunch, might be wildly wrong… but…
They changed DE only as a ‘lazy fix’ for compliance purposes, as it’s at least the EU default, perhaps a ‘bug’ allowed/set higher previously.
… TP-Link was fined in the US some time ago, for making over-power too easy/not restricted enough.
… and given the FCC plans to block foreign made routers, GL are trying to get their ducks in a row.
But at the end of the day, if devices are operating over the legal power limits, it is what it is - GL have to make sure their devices are compliant. Unfortunately.
Agreed.
Sod’s law though, I’ve lost total control of my Tapo C660 Wi-Fi camera, just at the same time I was having this firmware downgraded, but despite it only being 8 months old and reset 5 times, still no control or live feed, despite Wi-Fi being strong. Just funny how this has happened at the same time as this Router firmware was re-flashed back to 4.8.3 or probably just my conspiracy theory going overboard. Being returned for a replacement as it will give detection notifications, but no live feed or control from the App, so maybe the internal Receiver / transmitter has died or been reduced to a pittance. I will never know now.
I'm using OpenWrt 25.12.2 (newer than the one mentioned in the GitHub issue) and my transmission power is set to 30 dBm at 2.4 Ghz and 27 dBm at 5 Ghz. My country code is BR.
Gl.inet will need to fix this mess in 4.8.5 if possible.
or at least ensure that 4.9 addresses all the concerns raised around frequency strength.
Yes, I can confirm this finding.
Seems like the firmware updates has almost stopped sadly
If that were the case, this thread wouldn’t exist?! 
Disclaimer: AI post, I asked Claude to investigate the differences:
GL-MT6000 (Flint 2) — WiFi Signal Loss in 4.8.4 for DE (Germany) Users
Firmware: 4.8.3 → 4.8.4
Device: GL.iNet GL-MT6000 (Flint 2)
Affected: Users with country code set to DE (Germany)
Symptom: Severely degraded WiFi signal / range after upgrading to 4.8.4
Workaround: Changing country to any non-DE/non-JP value (e.g. GB) restores signal
Root Cause (Binary Analysis)
I diffed the two firmware images by extracting the squashfs root filesystems and
comparing them. Two changes interact to cause the issue:
Change 1 — etc/init.d/gl-txpower-init: DE added to SKU enforcement
In 4.8.3, only Japan (JP) had SKU power limiting enforced on boot. 4.8.4 adds DE:
# 4.8.3 — DE falls through to the wildcard, SKUenable forced to 0 (disabled)
case "$mt798x11_country" in
"JP")
sed -i "s/SKUenable=[^ ]*/SKUenable=1/" $file_b0
sed -i "s/SkuTableIdx=[^ ]*/SkuTableIdx=0/" $file_b0
;;
*)
sed -i "s/SKUenable=[^ ]*/SKUenable=0/" $file_b0 # <-- DE lands here
;;
esac
# 4.8.4 — DE now explicitly sets SKUenable=1 and SkuTableIdx=1
case "$mt798x11_country" in
"JP")
sed -i "s/SKUenable=[^ ]*/SKUenable=1/" $file_b0
sed -i "s/SkuTableIdx=[^ ]*/SkuTableIdx=0/" $file_b0
;;
"DE") # <-- NEW in 4.8.4
sed -i "s/SKUenable=[^ ]*/SKUenable=1/" $file_b0
sed -i "s/SkuTableIdx=[^ ]*/SkuTableIdx=1/" $file_b0
;;
*)
sed -i "s/SKUenable=[^ ]*/SKUenable=0/" $file_b0
;;
esac
This applies to both the 2.4 GHz (file_b0) and 5 GHz (file_b1) radios.
Change 2 — lib/modules/5.4.238/mt_wifi.ko: SKU table values broken
The WiFi driver contains 21 embedded SKU Power Limit Tables (unit: 0.5 dBm).
In 4.8.4, the table at SkuTableIdx=1 — which is now activated for DE — had
2,312 values changed from 60 to 10:
| Value | In 0.5 dBm units | Meaning |
|---|---|---|
60 |
30 dBm (1W) | Effectively uncapped — above any legal WiFi max |
10 |
5 dBm | Hard cap — severely limits transmit power |
Example from the 2.4 GHz table (every channel, every rate):
# 4.8.3 (SkuTableIdx=1, 2.4G)
Ch1 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 ...
Ch2 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 ...
...
# 4.8.4 (SkuTableIdx=1, 2.4G)
Ch1 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 ...
Ch2 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 ...
...
The same pattern repeats across all channels on both 2.4 GHz and 5 GHz.
The correct DE regulatory limits should be ~40 (20 dBm) for 2.4 GHz
and ~46 (23 dBm) for 5 GHz — not 10 (5 dBm).
This looks like a placeholder/zeroed-out table that was never populated with
real DE regulatory values before the firmware was released.
Why Other Countries Are Unaffected
For any country other than JP or DE, the init script sets SKUenable=0,
which bypasses the SKU table entirely. The driver then applies only the
regulatory domain limits from the wireless regdb — so signal is normal.
DE is the only country newly added to the SKU enforcement path in 4.8.4,
pointing at a broken table. JP was already there in 4.8.3 and presumably
has a correctly populated table at SkuTableIdx=0.
Verification Steps
Run these on your router after upgrading to 4.8.4 with country set to DE:
# 1. Check your country code
uci get wireless.radio0.country
cat /proc/gl-hw-info/country_code
# 2. Find your WiFi profile paths
cat /etc/wireless/l1profile.dat
# 3. Check SKUenable state on both radios
# (substitute actual paths from l1profile.dat output above)
grep SKUenable /etc/wireless/mt7986.dat
grep SKUenable /etc/wireless/mt7986_5g.dat
grep SkuTableIdx /etc/wireless/mt7986.dat
grep SkuTableIdx /etc/wireless/mt7986_5g.dat
If you see SKUenable=1 and SkuTableIdx=1 on either radio while country=DE,
that confirms the bug is active on your device.
Temporary Workaround
Change country to GB (United Kingdom) in the GL.iNet admin panel or via CLI:
uci set wireless.radio0.country='GB'
uci set wireless.radio1.country='GB'
uci commit wireless
wifi reload
Signal should immediately return to normal. UK/EU regulatory limits for
2.4 GHz and 5 GHz are essentially identical to DE in practice.
Alternatively, downgrade to 4.8.3 until a fix is released.
Fix Required
GL.iNet needs to either:
- Populate
SkuTableIdx=1with correct DE regulatory power limits inmt_wifi.ko
(replacing the placeholder10values with real values per ETSI/BNetzA limits), or - Revert DE from SKU enforcement until the table is correctly populated
Analysis performed by binary diff of squashfs root filesystems extracted from
both firmware images. The .text (compiled code) section of mt_wifi.ko is
identical between versions — only the .data section (power tables) changed.
2 Likes
Follow up:
The problem is they clearly built the enforcement plumbing before the actual DE power table was ready.
SkuTableIdx=1 got wired up in the init script, but the corresponding data in mt_wifi.ko was left as the placeholder 10 (5 dBm) values instead of real BNetzA-compliant limits.
It’s a classic case of a compliance deadline forcing a firmware release before all the pieces were actually finished — the DE regulatory work got split across two releases and the second half (the correct table data) didn’t make it in.
The irony is that by shipping 10 (5 dBm), they’re now more non-compliant in the other direction — most DE regulatory minimums require devices to actually reach certain power levels for usability, and 5 dBm is well below any practical threshold.
More details on 2.4Ghz vs 5Ghz:
This is really interesting — the 5 GHz picture tells a much more nuanced story than 2.4 GHz.
2.4 GHz: Every single channel (Ch1–Ch14) is a flat 10 (5 dBm). Completely broken placeholder.
5 GHz — two completely different situations:
-
Ch36–Ch60 (UNII-1 and lower UNII-2A): Flat
10(5 dBm) — broken placeholder, same as 2.4 GHz. These are the most commonly used indoor 5 GHz channels — 36, 40, 44, 48 are typically the default channels on most routers. -
Ch184, 188, 192, 196, 8, 12, 16 (upper UNII-2C/UNII-3 range): Real, varied values — per-rate limits ranging from ~5–10.5 dBm. These look like genuinely calculated regulatory values.
This actually reinforces the "incomplete work" theory rather than undermining it. Someone clearly started populating the DE regulatory data for the upper 5 GHz channels and simply never got to the lower channels or 2.4 GHz before the firmware shipped. The upper channels also happen to be the DFS channels that German regulators scrutinise most closely — so it's plausible the compliance work started there and ran out of time.
The practical impact for a DE user: your default 5 GHz channels (36/40/44/48) are capped at 5 dBm, 2.4 GHz completely neutered, while channels above 100 that almost no one uses by default might actually be fine.
What the ETSI standards actually require for Germany/EU
ETSI defines two EIRP limits for 2.4 GHz: 18 dBm for CCK (802.11b rates) and 20 dBm for OFDM (everything else). For 5 GHz, channels 36–64 are limited to 23 dBm, while channels 100–140 allow up to 30 dBm. Wordpress
In the driver's 0.5 dBm units, those translate to:
| Band | Channels | ETSI Max | Should be in table | 4.8.4 actual | Error |
|---|---|---|---|---|---|
| 2.4G | Ch1–13, CCK | 18 dBm | 36 | 10 | ✗ −13 dBm |
| 2.4G | Ch1–13, OFDM/HT/HE | 20 dBm | 40 | 10 | ✗ −15 dBm |
| 5G | Ch36–48 (UNII-1) | 23 dBm | 46 | 10 | ✗ −18 dBm |
| 5G | Ch52–64 (UNII-2A) | 23 dBm | 46 | 10 | ✗ −18 dBm |
| 5G | Ch100–140 (UNII-2C) | 30 dBm | 60 | ~10–21 | ? |
The 10 (5 dBm) values aren't a conservative interpretation of DE regulations — they're 6–16x below what ETSI actually permits. No compliance rationale explains them. They're clearly uninitialized placeholder values, not regulatory data.
The Ch100–140 values with real per-rate numbers are interesting — they look like they might be a MediaTek backoff table (per-rate TX power reduction to meet spectral mask requirements) rather than a ceiling table, which would put them in the right ballpark. But that's a separate question from the broken flat-10 entries everywhere else.
The fix GL.iNet needs to ship is straightforward: replace all the flat 10 entries with the correct ETSI ceilings (36/40 for 2.4 GHz, 46 for Ch36–64) and verify the Ch100–140 values are intentional.
4 Likes
It would seem uncertain that they would leave such a bug in this release but then this release was full of bugs from the release day itself.
Your analysis is really helpful thanks. FWIW I normally avoid trying beta firmwares, but after seeing the drop in wifi signal with 4.8.4 I thought I would try 4.8.5 beta. Its wifi performance appears to revert back to 4.8.3 so perhaps 4.8.5 contains the fixes you have suggested?
Date stamp before 4.8.4 I think? 
I think it’s doesn’t have the changes instead.
I emailed support and received the likely ‘copy paste’ reply about the intended power level changes in this release.
I asked them to review Claude’s findings in the posts above - they said they would.
I've had a Homer Simpson moment - D'oh!
So 4.8.5 beta isn’t much of a beta
1 Like
I experienced the same Wi-Fi signal degradation on firmware 4.8.4. Reverting to 4.8.3 resolved the issue. Given the lack of information in the 4.8.4 release notes, it feels like GL.iNet is neglecting its user base
They clearly don't care
I cant regain anything higher than 100mw in LuCI even went back to 4.8.3 and country still set to PA.
Did the 4.8.4 updates on both my Flint 2s without thinking of this outcome.