Bug 177846 - [ath] [net80211] net80211 TX power limit isn't correctly implemented for the BSS node and when the TX power limit is changed
Summary: [ath] [net80211] net80211 TX power limit isn't correctly implemented for the ...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-wireless (Nobody)
Depends on:
Reported: 2013-04-14 05:40 UTC by Adrian Chadd
Modified: 2018-05-28 19:47 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Chadd freebsd_committer 2013-04-14 05:40:00 UTC
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.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2013-04-14 05:47:38 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-wireless

Over to maintainer(s).
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:47:46 UTC
batch change:

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.