On Tue, Sep 20, 2011 at 3:54 PM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: > On 2011-09-21 12:37 AM, Luis R. Rodriguez wrote: >> >> On Tue, Sep 20, 2011 at 2:52 PM, Felix Fietkau<nbd@xxxxxxxxxxx> wrote: >>> >>> On 2011-09-20 11:26 PM, Luis R. Rodriguez wrote: >>>> >>>> On Tue, Sep 20, 2011 at 2:04 PM, Felix Fietkau<nbd@xxxxxxxxxxx> >>>> 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. Agreed, the above example shows not the primary changing but the extension channel changing. I can't think of an issue with it at this moment though. Luis -- 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
