From: Felix Fietkau <nbd@openwrt.org>
To: "Luis R. Rodriguez" <mcgrof@frijolero.org>
Cc: Johannes Berg <johannes@sipsolutions.net>,
Javier Cardona <javier@cozybit.com>,
Alexander Simon <an.alexsimon@googlemail.com>,
linux-wireless@vger.kernel.org
Subject: Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS
Date: Tue, 20 Sep 2011 23:04:43 +0200 [thread overview]
Message-ID: <4E78FFEB.1090301@openwrt.org> (raw)
In-Reply-To: <CAB=NE6WhaNpjpernCGY9skU+e+cUurPxi7r-FKaeH5iybeqGEg@mail.gmail.com>
On 2011-09-20 10:18 PM, Luis R. Rodriguez wrote:
> On Tue, Sep 20, 2011 at 12:31 PM, Felix Fietkau<nbd@openwrt.org> wrote:
>> On 2011-09-20 9:05 PM, Luis R. Rodriguez wrote:
>>>
>>> On Tue, Sep 20, 2011 at 11:46 AM, Felix Fietkau<nbd@openwrt.org> wrote:
>>>>
>>>> On 2011-09-20 8:38 PM, Luis R. Rodriguez wrote:
>>>>>
>>>>> On Tue, Sep 20, 2011 at 11:21 AM, Felix Fietkau<nbd@openwrt.org>
>>>>> wrote:
>>>>>>
>>>>>> On 2011-09-20 8:12 PM, Luis R. Rodriguez wrote:
>>>>>>>
>>>>>>> On Tue, Sep 20, 2011 at 5:21 AM, Johannes Berg
>>>>>>> <johannes@sipsolutions.net> wrote:
>>>>>>>>
>>>>>>>> On Mon, 2011-09-19 at 17:46 +0200, Alexander Simon wrote:
>>>>>>>> That seems pretty complex too ...
>>>>>>>>
>>>>>>>> I don't really know. As I said, I think I'd be happy with an
>>>>>>>> implementation that maybe doesn't fully implement everything as
>>>>>>>> long
>>>>>>>> as
>>>>>>>> it considers the trade-offs.
>>>>>>>
>>>>>>> The same questions come up with HT support and 802.11s, as per
>>>>>>> Javier
>>>>>>> this is not really well spelled out in the spec. My recommendation
>>>>>>> is
>>>>>>> to just support for now the most simple case and let us not entangle
>>>>>>> ourselves with the complexities of handling trying to merge
>>>>>>> different
>>>>>>> setups. So only enable peering up for adhoc or mesh if and only if
>>>>>>> the
>>>>>>> observed IE matches our own supported HT caps or target
>>>>>>> configuration.
>>>>>>> If a legacy STA tries to peer up with an HT IBSS, this would simply
>>>>>>> be
>>>>>>> rejected. We can leave off handling the change in configuration
>>>>>>> later
>>>>>>> for userspace, but do not see this as being a requirement for
>>>>>>> supporting HT for IBSS or Mesh. The simpler the better, so long as
>>>>>>> we
>>>>>>> simply respect the spec.
>>>>>>
>>>>>> I disagree. That'll make it useless for real deployments, which are
>>>>>> often a
>>>>>> mix of HT and non-HT devices.
>>>>>
>>>>> I'm not saying to not do it at all, I'm saying to start off with basic
>>>>> support *first* and *later* worry about the mixing.
>>>>
>>>> Simply sticking with the configured HT opmode is also simple, but it's a
>>>> lot
>>>> more practical.
>>>
>>> Just need to deal with the complexity, the complexity question is
>>> where do we handle this, verifying it respects the standard, and
>>> actually getting the work done. With AP mode of operation hostapd
>>> already does all this for us so if we want to support IBSS and Mesh
>>> without hostapd we'd need to figure out where to stuff this code. In
>>> the long run this would need to be resolved for both IBSS and Mesh. We
>>> can wait for all this work to get done or get a simple taste of basic
>>> HT support for both modes by sticking to the supported HT mode based
>>> on the observed beacons.
>>
>> HT capabilities are already handled properly, the main issue is handling the
>> HT opmode. For that, the only important bit is whether we're using HT40+,
>> HT40- or HT20. The code can easily just fall back to HT20 when the HT opmode
>> of the peer is incompatible with the local HT opmode.
>
> How about verifying that HT40 primary, secondary channel pair is
> allowed per as IEEE 802.11n Annex J on each peer? In the AP case we do
> this centrally, but for IBSS and Mesh, does each peer have to go on
> and do the check? If each peer does the check, and change settings,
> how do we go about changing the configuration of the established HT
> configuration? Where will this code go? Currently this goes into
> hostapd for APs.
This is not really an IBSS specific issue. It applies to WDS or monitor
mode as well. If we want to properly enforce Annex J channel pairs, this
needs to be moved to cfg80211.
- Felix
next prev parent reply other threads:[~2011-09-20 21:04 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-17 22:14 [PATCH v3 1/3] nl80211: Parse channel type attribute in an ibss join request Alexander Simon
2011-09-17 22:14 ` [PATCH v3 2/3] mac80211: Add HT helper functions Alexander Simon
2011-09-19 12:55 ` Johannes Berg
2011-09-19 13:01 ` Alexander Simon
2011-09-17 22:14 ` [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS Alexander Simon
2011-09-17 22:54 ` Alexander Simon
2011-09-19 13:04 ` Johannes Berg
2011-09-19 15:46 ` Alexander Simon
2011-09-20 12:21 ` Johannes Berg
2011-09-20 18:12 ` Luis R. Rodriguez
2011-09-20 18:21 ` Felix Fietkau
2011-09-20 18:38 ` Luis R. Rodriguez
2011-09-20 18:46 ` Felix Fietkau
2011-09-20 19:05 ` Luis R. Rodriguez
2011-09-20 19:31 ` Felix Fietkau
2011-09-20 20:18 ` Luis R. Rodriguez
2011-09-20 21:04 ` Felix Fietkau [this message]
2011-09-20 21:26 ` Luis R. Rodriguez
2011-09-20 21:52 ` Luis R. Rodriguez
2011-09-20 22:09 ` Felix Fietkau
2011-09-20 22:39 ` Luis R. Rodriguez
2011-09-20 21:52 ` Felix Fietkau
2011-09-20 22:37 ` Luis R. Rodriguez
2011-09-20 22:54 ` Felix Fietkau
2011-09-20 23:04 ` Luis R. Rodriguez
2011-09-20 18:55 ` Javier Cardona
2011-09-19 12:52 ` [PATCH v3 1/3] nl80211: Parse channel type attribute in an ibss join request Johannes Berg
2011-09-19 13:18 ` Alexander Simon
2011-09-19 13:32 ` 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=4E78FFEB.1090301@openwrt.org \
--to=nbd@openwrt.org \
--cc=an.alexsimon@googlemail.com \
--cc=javier@cozybit.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=mcgrof@frijolero.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).