mt7996: TX power limit accepted and reported but has no effect on transmitted power (ASUS ZenWiFi BT8, single-wiphy multi-radio)

Open
  • Is something wrong?
#1,140 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c, linux
Domain
embedded-iot, networking, operating-systems

Research direction

Start by reproducing the per-interface and wiphy-wide limits with the listed iw commands, comparing beacon and mesh data-frame measurements. Then trace MT7996E txpower handling in the driver and inspect /sys/kernel/debug/ieee80211/phy0/mt76/; done means requested limits produce corresponding transmitted-power changes on both beacons and data frames.

Written by the indexing model from the issue text.

Description

Summary

On an ASUS ZenWiFi BT8 (MT7996E), setting a TX power limit is accepted and iw reports the new value, but the power actually transmitted does not change. This applies to both the per-interface limit (iw dev <vif> set txpower limit) and the wiphy-wide limit (iw phy phy0 set txpower limit), to beacons and to data frames, on OpenWrt 25.12.5 and on a current snapshot.

Hardware and software
  • Device: ASUS ZenWiFi BT8 (asus,zenwifi-bt8), target mediatek/filogic, MT7996E tri-band (2.4/5/6 GHz) exposed as a single wiphy (phy0) with three radios.
  • Tested on:
    • OpenWrt 25.12.5 r33051-f5dae5ece4, kernel 6.12.94, kmod-mt7996e 2026.03.19~39c960c3
    • OpenWrt SNAPSHOT r36623-57072d9ebb, kernel 6.18.52, kmod-mt7996e 2026.09.01~be5ce791
  • Regulatory domain GB (DFS-ETSI). Two identical units about 10 m apart through masonry.
Steps to reproduce
  1. Unit A runs an AP on 5 GHz (ch 36 or 40, 80 MHz). Unit B stays a fixed distance away.
  2. On B, repeatedly scan A's channel and read A's beacon RSSI:
    iw dev <vif> scan freq 5200 ap-force; iw dev <vif> scan dump
  3. On A, step the limit and re-measure on B at each step:
    • iw dev phy0.1-ap0 set txpower limit 2300 | 1000 | 300
    • iw phy phy0 set txpower limit 2300 | 1000 | 300, then iw phy phy0 set txpower auto
  4. For data frames: with an 802.11s link between A and B on 6 GHz, generate traffic across it and read signal from iw dev phy0.2-mesh0 station get <A> on B while stepping A's wiphy limit.
Expected

A received-signal drop at B roughly equal to the change in limit (about 13 dB from 23 to 10 dBm, about 20 dB from 23 to 3 dBm).

Actual

iw dev ... info on A reports the new txpower each time. The signal measured at B does not change.

Beacons, 5 GHz, B measuring A (3 scans per step, dBm):

Limit on A 25.12.5, per-vif Snapshot, per-vif Snapshot, wiphy-wide
23 dBm -58, -63, -59 -53, -53, -54 -54, -54, -54
10 dBm -57, -63, -57 -54, -54, -56 -54, -54, -54
3 dBm -57, -58, -57 -53, -53, -53 -54, -54, -54

Also on 25.12.5, wiphy-wide on the other unit: auto (reported 26 dBm) gave -65/-58/-59, 10 dBm gave -57/-63/-57, 3 dBm gave -60/-63/-58.

Data frames, 6 GHz 802.11s, 25.12.5, B measuring A (six samples per step): -64 at auto (reported 23 dBm), -64 at 10 dBm, -64 at auto again.

Notes
  • With the per-vif limit set on one 5 GHz AP interface, iw reports the lowest limit on every interface on that radio, including a mesh interface on the same channel. So the limit is aggregated per channel context as expected, but it does not appear to reach the hardware.
  • /sys/kernel/debug/ieee80211/phy0/mt76/ on this build has no txpower or SKU table to inspect.
  • The reverse problem (power capped very low because of zeroed EEPROM data on some MT7996E boards) has been reported elsewhere. This is different: here power stays at the maximum whatever is requested.
  • Practical impact: cell size cannot be reduced, so client roaming between two units depends entirely on steering.

Happy to run further tests or collect debug output.

Dominant language
C
Stars
895
Forks
461
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openwrt/mt76

All issues in openwrt/mt76

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.