<div dir="ltr">hi Jouni,<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 19, 2015 at 3:48 PM, Jouni Malinen <span dir="ltr"><<a href="mailto:j@w1.fi" target="_blank">j@w1.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Jun 17, 2015 at 04:18:13PM +0300, Ilan Peer wrote:<br>
> IEEE Std 802.11-2012 (10.15.3.2) states that the secondary<br>
> channel should be a channel with no other beacons, unless<br>
> beacons are detected on both the primary and secondary<br>
> channels.<br>
<br>
</span>Yes and just before that it states that the PRI/SEC channels shall be<br>
identical with a detected BSS unless there is already mix of different<br>
PRI/SEC channels which is an actual requirements (shall vs. should).<br>
<span class=""><br></span></blockquote><div>right. i probably attributed the behavior to the wrong paragraph.</div><div><br></div><div>anyway, the actual problem we encountered was when working with single-channel device, and having the following environment:</div><div>1. connect to 20mhz ap on channel 149</div><div>2. having another 40mhz ap on channels 153 + 149 </div><div>3. starting 40Mhz GO</div><div><br></div><div>the current code will cause the GO to fail, as although we are connected to channel 149, the ap will be finally started on channel 153 due to bss overlap.</div><div><br></div><div>it seems to me a bit weird to fail here (as we are already connected to an AP with the same control channel), but please tell if this is the expected behavior in such case :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> The current code doesn't check the existence of such<br>
> beacons, resulting in unnecessary switch in case<br>
> of HT20 ap on our primary channel + overlapping HT40 ap.<br>
<br>
</span>There is already a check for whether beacons are detected on SEC<br>
channel, but not on PRI and switches own configuration based on that.<br>
Could you please provide a more detailed example of this? I'd like to<br>
see the list of detected PRI/SEC channels and the local configuration in<br>
which case the unnecessary switch happens.<br>
<span class=""><br>
> Add check to consider this switch only if there are<br>
> no beacons on the primary channel.<br>
<br>
</span>I'm not sure I follow the logic here taken into account !pri_bss<br>
condition here would imply that sec_bss == 0, i.e., the earlier loop<br>
through scan results did not find a single BSS on either our PRI or SEC<br>
channels. How could this second loop find a match in such a case?<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div>you're right, i overlooked it.</div><div><br></div><div>thanks,</div><div>Eliad.</div></div></div></div>