I have several OpenWRT installations, all of which have been upgraded to 25.12.2 For all of them, when I set the transmit power level to 0 dBm the power shown on the LuCI screen is Default rather than 1 milliwatt. If I set the power level to 1 dBm I get 1 milliwatt. I believe 0 dBm should also return 1 milliwatt. I’m connecting to a very nearby Raspberry Pi so don’t want more power than needed.
Is this an error in the code?
Please open LuCI, go to Network, then Wireless and tell me the internal device name of your wireless adapter, for example radio0 or radio1.
1 Like
All my devices have radio0 and radio1 and both radios exhibit the same
behavior. When lowering the power level by steps they go down
to 1 dBm = 1 milliwatt but then go back up to the maximum power
of the device at 0 dBm rather than showing 1 milliwatt.
Please run the following commands via SSH and share the output:
uci get wireless.radio0.txpower
uci get wireless.radio1.txpower
iwinfo wlan0 info | grep Tx-Power
iwinfo wlan1 info | grep Tx-Power
And please open LuCI, go to Network, then Wireless, press F12, open the Console tab and enter the following:
document.querySelector('select[id*="txpower"]').options[1].value
Please share the output of all commands.
We can start by ignoring radio0 as I want maximum power there.
uci get wireless.radio1.txpower
0
iwinfo phy1-ap0 info | grep Tx-Power
Tx-Power: 23 dBm Link Quality: 67/70
But the following line appears in LuCI for radio1
Maximum transmit power 0 dBm (1 mW) - Current power: 23 dBm
And please open LuCI, go to Network, then Wireless, press F12, open the Console tab and enter the following:
document.querySelector('select[id*="txpower"]').options[1].value
document.querySelector('select[id*="txpower"]').options[1].value
VM605:1 Uncaught TypeError: Cannot read properties of null (reading 'options')
at :1:48
As you can see, radio1 is at maximum power,
BUT radio1 shows 0 power. What I want is 0 dBm,
which should be 1 milliwatt.
I ran a scan with another router and found that when I set
this router/radio at 0 dBm I get -51 dBm on the scan and when
I set this router/radio at 1 dBm I get -72 dBm on the scan,
the correct difference.
I really (still) don't understand this topic, why does it have to be '0'…?!
Doctor, doctor, it hurts if I do this.
Then don't do that.
…or in other words, if 1 dBm provides a reasonable setting (1.00 mW vs 1.26 mW), stick to that. I'm not the developer/ maintainer behind any of the involved packages, but for me personally, the priority of this issue would rate just behind mowing my (hypothetical) mother in law's lawn in Nome/ AK on the next 30th of February (oh, I need to book a flight crossing several Oceans first, quickly).
1 Like
Bug 1 — LuCI wireless.js — Display bug
When txpower is set to 0 dBm, the LuCI dropdown shows "driver default" instead of "0 dBm (1 mW)". The cause is a JavaScript type comparison error — the key is stored as a Number instead of a String. UCI always returns strings, so the comparison "0" === 0 fails.
Issue: https://github.com/openwrt/luci/issues/8536
Bug 2 — ucode mac80211.sh — Functional bug
When txpower is set to 0, the router transmits at maximum power. The cause is that 0 is falsy in ucode — the condition if (config.txpower) falls through to the else branch at value 0 and sets txpower to auto instead of fixed 000. The old shell version handled this correctly — the bug was introduced during migration to ucode.
Tested on five devices with three different chipsets — all show identical behavior. The OpenWrt One as the official reference device is also affected.
1 Like
This issue cannot be fully resolved at the OpenWrt level alone. The root cause is that nl80211 does not expose the minimum transmit power of the hardware. Without this value, iwinfo cannot build an accurate selection list and userspace will continue to show values that the hardware cannot actually apply.
A proposal to address this at the kernel level has been sent to the linux-wireless mailing list:
https://lore.kernel.org/linux-wireless/9ec6fd0b1c7392fce8c913a46c1b197e@posteo.de/T/#u
1 Like
This is a very nice looking report, Steffen.
Thanks for doing this.
Peter