All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@frijolero.org>
To: Paul Stewart <pstew@chromium.org>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	Sam Leffler <sleffler@google.com>,
	linux-wireless@vger.kernel.org
Subject: Re: [RFCv2] mac80211: Don't let regulatory make us deaf
Date: Thu, 23 Feb 2012 17:53:01 -0800	[thread overview]
Message-ID: <CAB=NE6XHpOdKsTFM3x_aMF7+jL6NKuB9_wS0eQRBYqAbQVw1ww@mail.gmail.com> (raw)
In-Reply-To: <CAMcMvshr_1gx0y55ne5wia03OaSASZAh1vvJyeY02v1yTwU4aQ@mail.gmail.com>

On Thu, Feb 23, 2012 at 7:14 AM, Paul Stewart <pstew@chromium.org> wrote:
> On Thu, Feb 23, 2012 at 6:59 AM, Johannes Berg
> <johannes@sipsolutions.net> 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@sipsolutions.net> 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?

  Luis

  reply	other threads:[~2012-02-24  1:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-21  5:25 [RFC] mac80211: Don't let regulatory make us deaf Paul Stewart
2012-02-21  5:25 ` [RFCv2] " Paul Stewart
2012-02-21 18:01   ` Mahesh
2012-02-23 13:39   ` Johannes Berg
2012-02-23 14:53     ` Sam Leffler
2012-02-23 14:59       ` Johannes Berg
2012-02-23 15:14         ` Paul Stewart
2012-02-24  1:53           ` Luis R. Rodriguez [this message]
2012-02-24  4:15             ` Paul Stewart
2012-02-21  5:25               ` [PATCH] " Paul Stewart
2012-02-24  4:25             ` [RFCv2] " Sam Leffler
2012-02-26 11:15   ` Johannes Berg
2012-02-26 11:25     ` Johannes Berg
2012-02-27 10:34       ` Johannes Berg
2012-02-27 11:32         ` Jouni Malinen
2012-02-27 11:38           ` Johannes Berg
2012-02-27 13:46             ` Jouni Malinen
2012-03-07  5:46               ` Paul Stewart
2012-03-07  7:36                 ` Johannes Berg
2012-03-07 18:40                   ` John W. Linville
2012-03-07 18:52                     ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAB=NE6XHpOdKsTFM3x_aMF7+jL6NKuB9_wS0eQRBYqAbQVw1ww@mail.gmail.com' \
    --to=mcgrof@frijolero.org \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pstew@chromium.org \
    --cc=sleffler@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.