From owner-freebsd-bugs@FreeBSD.ORG Sun Apr 14 04:40:00 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C1501CC7 for ; Sun, 14 Apr 2013 04:40:00 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A8535DB for ; Sun, 14 Apr 2013 04:40:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3E4e0Iq066613 for ; Sun, 14 Apr 2013 04:40:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3E4e0tj066612; Sun, 14 Apr 2013 04:40:00 GMT (envelope-from gnats) Resent-Date: Sun, 14 Apr 2013 04:40:00 GMT Resent-Message-Id: <201304140440.r3E4e0tj066612@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, adrian chadd Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A27A1C7D for ; Sun, 14 Apr 2013 04:36:39 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 73126C9 for ; Sun, 14 Apr 2013 04:36:39 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.5/8.14.5) with ESMTP id r3E4acOa011727 for ; Sun, 14 Apr 2013 04:36:38 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.5/8.14.5/Submit) id r3E4acmw011726; Sun, 14 Apr 2013 04:36:38 GMT (envelope-from nobody) Message-Id: <201304140436.r3E4acmw011726@red.freebsd.org> Date: Sun, 14 Apr 2013 04:36:38 GMT From: adrian chadd To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: misc/177846: [ath] [net80211] net80211 TX power limit isn't correctly implemented for the BSS node and when the TX power limit is changed X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 04:40:00 -0000 >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: