[PATCH] hostapd: add check for overlapping legacy BSS

[Jouni Malinen]

On Mon, May 12, 2014 at 11:29:12PM +0530, Rajkumar Manoharan wrote:
> On Mon, May 12, 2014 at 06:28:26PM +0300, Jouni Malinen wrote:
> > On Sat, May 03, 2014 at 07:56:07PM +0530, Rajkumar Manoharan wrote:
> > > Before bringing up 20/40 MHz BSS, a scan is triggered to identify
> > > overlapping BSS. If there is any legacy BSS present within the affected
> > > range, then 40 MHz operation should be rejected and BSS should start
> > > with 20 MHz.
> > 
> > Why would we do that? What's so different about legacy (as in "non-HT"
> > in this case) BSS and HT 20 MHz BSS that would justify such difference?
> > Can you please point me to the rule in the IEEE Std 802.11-2012 20/40
> > coex requirements that this patch implements?
> 
> IEEE Std 802.11-2012 - 10.15.12: Switching between 40 MHz and 20 MHz
> 
> An FC HT AP 2G4 shall reevaluate the value of the local variable 20/40
> Operation Permitted (see 10.15.3.2) when either of the following events occurs:
> 	? A BSS channel width trigger event TE-A is detected.
> :
> :
> 
> TE-A: On any of the channels of the channel set defined in Clause 19, reception
> of a Beacon frame that does not contain an HT Capabilities element.

That is not a rule defining when 40 MHz channel is allowed; that's a
rule describing when that determination needs to re-evaluated. While I
agree that TE-A is talking about the case of a non-HT BSS, I cannot find
such language from 10.15.3.2 which includes the rules on how to
determine "20/40 Operation Permitted" value. I'd assume this non-HT 20
MHz BSS would be in the OT_i set, if it were reported by an association
station, but the source code change proposed here is not processing that
information; it is processing results from a local scan performed by the
AP. The applicable rule for that seems use language "at least one 20 MHz
BSS that was detected within the AP's BSA" which does not say anything
about HT vs. non-HT. Consequently, I do not understand what this patch
is trying to do and how it matches the coex requirements.

-- 
Jouni Malinen                                            PGP id EFC895FA