From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-tul01m020-f174.google.com ([209.85.214.174]:51901 "EHLO mail-tul01m020-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754754Ab2BXEPt convert rfc822-to-8bit (ORCPT ); Thu, 23 Feb 2012 23:15:49 -0500 Received: by obcva7 with SMTP id va7so2322484obc.19 for ; Thu, 23 Feb 2012 20:15:49 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20120221060932.8A38C20517@glenhelen.mtv.corp.google.com> <20120221131946.AC1AD20578@glenhelen.mtv.corp.google.com> <1330004364.3448.8.camel@jlt3.sipsolutions.net> <1330009145.3448.13.camel@jlt3.sipsolutions.net> Date: Thu, 23 Feb 2012 20:15:48 -0800 Message-ID: (sfid-20120224_051553_748917_2D6AEA92) Subject: Re: [RFCv2] mac80211: Don't let regulatory make us deaf From: Paul Stewart To: "Luis R. Rodriguez" Cc: Johannes Berg , Sam Leffler , linux-wireless@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Thu, Feb 23, 2012 at 5:53 PM, Luis R. Rodriguez wrote: > On Thu, Feb 23, 2012 at 7:14 AM, Paul Stewart wrote: >> On Thu, Feb 23, 2012 at 6:59 AM, Johannes Berg >> wrote: >>> >>> On Thu, 2012-02-23 at 06:53 -0800, Sam Leffler wrote: >>> > On Thu, Feb 23, 2012 at 5:39 AM, Johannes Berg >>> > wrote: >>> > > On Mon, 2012-02-20 at 21:25 -0800, Paul Stewart wrote: >>> > >> When regulatory information changes our HT behavior (e.g, >>> > >> when we get a country code from the AP we have just associated >>> > >> with), we should use this information to change the power with >>> > >> which we transmit, and what channels we transmit.  Sometimes >>> > >> the channel parameters we derive from regulatory information >>> > >> contradicts the parameters we used in association.  For example, >>> > >> we could have associated specifying HT40, but the regulatory >>> > >> rules we apply may forbid HT40 operation. >>> > >> >>> > >> In the situation above, we should reconfigure ourselves to >>> > >> transmit in HT20 only, however it makes no sense for us to >>> > >> disable receive in HT40, since if we associated with these >>> > >> parameters, the AP has every reason to expect we can and >>> > >> will receive packets this way.  The code in mac80211 does >>> > >> not have the capability of sending the appropriate action >>> > >> frames to signal a change in HT behaviour so the AP has >>> > >> no clue we can no longer receive frames encoded this way. >>> > >> In some broken AP implementations, this can leave us >>> > >> effectively deaf if the AP never retries in lower HT rates. >>> > >> >>> > >> This change breaks up the channel_type parameter in the >>> > >> ieee80211_enable_ht function into a separate receive and >>> > >> transmit part.  It honors the channel flags set by regulatory >>> > >> in order to configure the rate control algorithm, but uses >>> > >> the capability flags to configure the channel on the radio, >>> > >> since these were used in association to set the AP's transmit >>> > >> rate. >>> > > >>> > > Quite the stupid APs, obviously ... >>> > >>> > Actually the AP is operating correctly (modulo the question of whether >>> > HT40 may be used in kr). >>> >>> Ah, yes. I was thinking the AP was actually saying you can't use 40 MHz, >>> but it's obviously just saying that you're in KR and our database says >>> you then can't use 40 Mhz... >> >> More succinctly, Sam is posing the possibility that a STA we should >> ignore regulatory on TX as well as RX in this situation, since the AP >> clearly negotiated HT40 with us. > > If the AP was right and we were allowed to use this that'd be fine but > consider the case where the AP is wrong, they'd we'd be doing the > wrong thing. If the AP believes HT40 is allowed but our wireless-regdb > disagrees we trust our wireless-regdb more, by design. > > Did I understand your question correctly? I think you did. As such, I'll clean the code up as per Johannes' suggestion, fix up another call to rate_control_rate_update I found in rx.c and add a [PATCH] to this thread. -- Paul > >  Luis