There's a few bugs relating to TPC (transmit power control); this is but one.
When a VAP is created and the BSS node gets created, the BSS node inherits the ic maximum tx power limit:
ni->ni_txpower = ic->ic_txpowlimit; /* max power */
However, ic_txpowlimit by default is set to:
ieee80211_var.h:#define IEEE80211_TXPOWER_MAX 100 /* .5 dbM (XXX units?) */
. which is 50dBm. Way, way too high by default. But that's fine, shouldn't setting the regulatory and channel TX power limit change the ic_txpowlimit value? Nope.
Ok, so what's this actually mean?
It means that when the BSS node is created, it inherits the TX power from the IC, but the IC value is quite high. So the driver has to clamp it. but ath(4) doesn't at all clamp it (besides clamping it at 0x3f, the maximum TX power that can fit in the TX power descriptor / register fields.)
Now, if you then change the TX power via 'ifconfig wlanX txpower Y', it does change the ic_txpowlimit value, but it doesn't affect the BSS node tx power. Nor, i suspect, the TX power limit of any previously created nodes.
So what likely should occur here?
* does net80211 get taught how to update the TX power limit for each node when one does a TX power reconfigure?
* does each driver for now just use the MIN() of the ic_txpowlimit _and_ the ni->ni_txpower value?
The latter is probably better. It won't be atomic, but it'll at least work.
It's likely that I'll just have to teach ath(4) to look at the ic_txpowlimit value when calculating the maximum tx power to send to a node.
There are other issues here; like how the TX descriptor code isn't storing maximum TX power limit values in the HAL, so the HAL TX code can't actually clamp the required TX power to the maximum allowed at the given rate. Thus higher rates will distort. But that'll be in another bug.
* Create an ath(4) based hostap VAP, on something that we vaguely support TPC on (say, AR5212/AR5413 series NICs);
* enable TPC (sysctl dev.ath.X.tpc=1);
* bring it up;
* change the txpower;
* look at how the output power level doesn't change.
Over to maintainer(s).
For bugs that match the following
- Status Is In progress
- Untouched since 2018-01-01.
- Affects Base System OR Documentation
Reset to open status.
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.