Diagnosing Low txpower on OpenWrt MediaTek Radios

by

When txpower looks lower than expected on an OpenWrt MediaTek radio, the most common diagnostic mistake is treating four different values as one. The request in /etc/config/wireless, the runtime value reported by iw, the regulatory ceiling for the country and channel, and the RSSI measured by a client are not interchangeable.

option txpower is a requested ceiling, not an instruction that forces the hardware to transmit at that exact level. Actual power cannot exceed the limits imposed by the regulatory domain, channel and width, EEPROM and calibration data, driver, or firmware. A low number alone therefore does not prove an mt76 regression, and selecting another country to bypass a limit is not a valid fix.

Separate the four values first

Value Where to inspect it What it means
Configured request uci -q get wireless.radio0.txpower The user-requested ceiling. An absent value does not mean unrestricted power
Runtime report iw dev wlan0 info The value reported for the active interface. Reporting can be limited on some devices
Regulatory ceiling iw reg get, iw phy phy0 info The permitted range for the country, frequency, channel width, and DFS conditions
Link quality iw dev wlan0 station dump measured repeatedly from the same location RSSI, retries, bitrate, and throughput. These are not controlled by AP txpower alone

OpenWrt documentation requires the country where the device is actually installed and explains that regulatory limits cap hardware capable of higher output. The Linux wireless cfg80211 process also preserves the device’s original limits and combines them with the active regulatory domain and driver or EEPROM hints.

Map the UCI radio to the PHY and interface

Do not assume that radio0, phy0, and wlan0 always identify the same physical radio. Record the device, OpenWrt version, UCI radio, and active interface together.

ubus call system board
uci show wireless | grep '=wifi-device'
iw dev
iw reg get

Keep the release and target from ubus call system board with the wiphy number shown by iw dev. Replace radio0, phy0, and wlan0 in the next commands with the names you just identified.

uci -q get wireless.radio0.country
uci -q get wireless.radio0.txpower
iw phy phy0 info
iw dev wlan0 info
logread | grep -iE 'mt76|firmware|eeprom|calib|regulatory|txpower'
dmesg | grep -iE 'mt76|firmware|eeprom|calib|regulatory|txpower'

If iw reg get starts with country 00, the conservative world regulatory domain may be active. Correcting the country still cannot override a lower ceiling from EEPROM, calibration data, or firmware, so a country change alone does not establish whether the driver is defective.

Only two configuration changes are appropriate here

Back up the wireless configuration first. Reloading Wi-Fi disconnects clients, so establish a wired management path or recovery plan before doing this over a wireless SSH session.

cp /etc/config/wireless /root/wireless.before-txpower
ls -l /root/wireless.before-txpower

1. Set the actual installation country

This example is for radio0 operating in South Korea. Use the ISO 3166-1 alpha-2 code for the device’s real installation location elsewhere.

uci set wireless.radio0.country='KR'
uci commit wireless
wifi reload
iw reg get

A DFS channel might not become available until the required channel-availability check completes. Do not misclassify a short outage immediately after reload as a transmit-power failure.

2. Remove a stale low override

Run this only when an explicit txpower value exists and the goal is to return to the driver default and regulatory ceiling.

uci -q delete wireless.radio0.txpower
uci commit wireless
wifi reload
uci -q get wireless.radio0.txpower

No output from the final command means there is no explicit override. It does not mean that transmit power is unlimited or that the hardware maximum is guaranteed.

Compare conditions, not just one number

  • Use the same radio, channel, channel width, and country code.
  • From the same client and location, compare RSSI, transmit bitrate, retries, and throughput.
  • Do not use a 2.4 GHz result as the expected baseline for a 5 GHz radio.
  • When comparing firmware releases, match only the settings required for the test instead of restoring an entire old configuration.
  • Do not raise the requested ceiling while firmware, EEPROM, or calibration errors remain.
Observation Next conclusion
Removing a low UCI override changes the runtime value to the expected range The configured ceiling caused the symptom
The country was wrong and correcting it changes channels or limits The regulatory-domain configuration caused the difference
The same country and settings fail only on one image Collect the release, target, and mt76 logs to investigate a regression
The reported value is low but link quality is unchanged at the same location Separate a reporting problem from actual RF performance
EEPROM or calibration errors repeat Investigate board data and firmware instead of bypassing regulation

Do not use these shortcuts

  • Do not select a country other than the actual location to raise the ceiling.
  • Do not infer antenna output or legal EIRP from one iw number.
  • Do not treat low RSSI as proof of an AP txpower problem. Client power, distance, interference, and antennas also matter.
  • Do not apply unofficial regulatory database patches or EEPROM bypass instructions.

Build a useful issue report

If settings and the regulatory domain are correct but the problem repeats only on a specific OpenWrt image, include ubus call system board, iw reg get, the affected PHY information, mt76 logs, board name, image name, channel, and width. That evidence can separate a display limitation, board calibration issue, and real regression far better than a report that only says txpower is low.

Official documentation

Related guides for the next troubleshooting step