Re: [RFCv2] mac80211: Don't let regulatory make us deaf

From: Johannes Berg <johannes@sipsolutions.net>
To: Paul Stewart <pstew@chromium.org>
Cc: linux-wireless@vger.kernel.org,
	Rajkumar Manoharan <rmanohar@qca.qualcomm.com>,
	Arik Nemtsov <anamtsov@gmail.com>,
	Eliad Peller <eliad@wizery.com>, Jouni Malinen <j@w1.fi>
Subject: Re: [RFCv2] mac80211: Don't let regulatory make us deaf
Date: Sun, 26 Feb 2012 12:25:37 +0100	[thread overview]
Message-ID: <1330255537.4401.10.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <1330254954.4401.9.camel@jlt3.sipsolutions.net> (sfid-20120226_121611_944331_8D721289)

On Sun, 2012-02-26 at 12:15 +0100, 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.
> 
> Looking at this in mac80211 (ieee80211_enable_ht) in more detail for
> other reasons, I believe our current behaviour is wrong in other cases
> as well, not just the regulatory case.
> 
> If the AP is advertising HT40, but 40MHz-intolerant at the same time, I
> believe we should also configure the channel to HT40, and prohibit using
> 40 MHz TX for the time in which 40MHz-intolerant is set. Otherwise, when
> the AP changes the 40MHz-intolerant flag, we may reconfigure our channel
> too late to receive 40MHz transmissions. Also, some devices don't like
> having the channel reconfigured while associated and doing so would be
> particularly messy when we start talking about multi-channel operation.
> 
> I think overall better behaviour would be to set up the HT channel
> already in ieee80211_mgd_auth() according to what the AP advertises,

Correction: ieee80211_mgd_assoc(), during auth we don't yet know what
ciphers we'll use etc. so we don't yet know if HT will be disabled.
However, during auth we also don't care about the channel type, so
there's no problem for multi-channel.

> disregarding regulatory information and 40MHz-intolerant bits. While
> associated, the only possible changes would be
>  1) changes in HT opmode (protection, non-GF/non-HT sta etc.)
>  2) 40MHz-intolerant changes (e.g. when such a STA joins)
> This would affect both the driver and rate control, and for drivers
> having rate control built-in we need to also tell them directly.
> 
> Thoughts?
> 
> johannes
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 