misc/177846: [ath] [net80211] net80211 TX power limit isn't correctly implemented for the BSS node and when the TX power limit is changed

adrian chadd adrian at FreeBSD.org
Sun Apr 14 04:40:00 UTC 2013


>Number:         177846
>Category:       misc
>Synopsis:       [ath] [net80211] net80211 TX power limit isn't correctly implemented for the BSS node and when the TX power limit is changed
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Apr 14 04:40:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator:     adrian chadd
>Release:        -HEAD
>Organization:
>Environment:
>Description:
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:

ieee80211_alloc_node():
..
        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.


>How-To-Repeat:

* 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.

>Fix:
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.

>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list