Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

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 21:31:17 +0200	[thread overview]
Message-ID: <4E78EA05.6000005@openwrt.org> (raw)
In-Reply-To: <CAB=NE6XqT_ZUV7F+0ZvCs-WgxZnJn3onMiWNtBi=+eCkMZMgPA@mail.gmail.com>

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.

- Felix