On Thu, Feb 23, 2012 at 5:53 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxxxxx> wrote: > On Thu, Feb 23, 2012 at 7:14 AM, Paul Stewart <pstew@xxxxxxxxxxxx> wrote: >> On Thu, Feb 23, 2012 at 6:59 AM, Johannes Berg >> <johannes@xxxxxxxxxxxxxxxx> wrote: >>> >>> On Thu, 2012-02-23 at 06:53 -0800, Sam Leffler wrote: >>> > On Thu, Feb 23, 2012 at 5:39 AM, Johannes Berg >>> > <johannes@xxxxxxxxxxxxxxxx> 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? Yes, the point is that one must trust the AP otherwise you potentially have a sta that is not operating correctly within the BSS. There are obvious limits (e.g. you don't raise the tx power cap above the h/w limit) but in this case it makes no sense to have a sta sticking to HT20 when the AP says the BSS is using HT40. The local regulatory state should be used when starting up a master (ibss or infra) but overriding an AP in most cases will result in confusion. -Sam -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
