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

[Felix Fietkau <nbd@openwrt.org>]

On 2011-09-21 12:37 AM, Luis R. Rodriguez wrote:
> On Tue, Sep 20, 2011 at 2:52 PM, Felix Fietkau<nbd@openwrt.org>  wrote:
>>  On 2011-09-20 11:26 PM, Luis R. Rodriguez wrote:
>>>
>>>  On Tue, Sep 20, 2011 at 2:04 PM, Felix Fietkau<nbd@openwrt.org>    wrote:
>>>>
>>>>    If we want to properly enforce Annex J channel pairs, this needs to
>>>>    be moved to cfg80211.
>>>
>>>  This does not still address the issue of one peer finding out it
>>>  cannot deal with an HT40 pair and correcting the topology and
>>>  propagating this out. Not yet sure if for 802.11ac we'll need
>>>  something similar but its worth considering.
>>
>>  Don't think of it as a topology. Each node makes its own decisions about
>>  HT40+/HT40-/HT20.
>
> OK lets go with an example.
>
> Node A: HT40+
>     Primary: 5785 (157)
>     Extension: 5805 (161)
>
> Node B: HT20 as it finds a legacy AP with on 5805.
>    Channel: 5785 (157)
>
> Node C: HT40-
>    Primary:  5785 (157)
>    Extension: 5765 (153)
>
> So we want to support this setup?
>
> What if the network changes and we cannot use the original HT40 pair
> now but we can later? This applies even to today's hostapd AP setup
> and more rhetorical.
Whenever a node is not alone in an IBSS, it must keep the primary 
channel the same to be able to talk to its neighbors. If it cannot use 
its HT40 opmode because of overlap checks then it should just gracefully 
fall back to HT20. Refusal to join or randomly changing the primary 
channel would create big problems for bigger deployments, IBSS merging 
should always be considered potentially unreliable.

Most big ad-hoc mesh deployments use fixed channel and fixed cell-id for 
that reason.

- Felix