On Tue, Sep 20, 2011 at 3:09 PM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: > On 2011-09-20 11:52 PM, Luis R. Rodriguez wrote: >> >> On Tue, Sep 20, 2011 at 2:26 PM, Luis R. Rodriguez<mcgrof@xxxxxxxxxxxxx> >> wrote: >>> >>> On Tue, Sep 20, 2011 at 2:04 PM, Felix Fietkau<nbd@xxxxxxxxxxx> wrote: >>>> >>>> This is not really an IBSS specific issue. It applies to WDS or monitor >>>> mode >>>> as well. >>> >>> Excellent point! >>> >>>> 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. >> >> Sorry I meant section 11.14.3.2 which deals with neighboring BSSes >> from the scan list, the annex J stuff would still need to be done by >> all the initial radiators too though for a primary. > > If we need to handle this properly in the initial patch, then this can > probably only be done in a simple way by not supporting HT40 yet. Right, sorry I should have clarified my concern was the scanning aspect, not annex J. In this case I still do believe we can still support HT40 but the scan stuff can go out to iw, or this may be a good use case for stuffing some stuff into a shared library between iw / hostapd. The Mesh stuff will hopefully eventually be merged into hostapd, but for adhoc it seems overkill. I was actually more concerned about the mismatch on configuration rather than the scanning, but I think Annex J helps with this, by fixating primaries apart from each other. > It should still support joining an IBSS with a different HT opmode though. So long as the scan/check is done, sure. 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
