<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 28, 2015 at 6:24 PM, Jouni Malinen <span dir="ltr">&lt;<a href="mailto:j@w1.fi" target="_blank">j@w1.fi</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, Jun 21, 2015 at 11:56:23AM +0300, Eliad Peller wrote:<br>
&gt; anyway, the actual problem we encountered was when working with<br>
&gt; single-channel device, and having the following environment:<br>
&gt; 1. connect to 20mhz ap on channel 149<br>
&gt; 2. having another 40mhz ap on channels 153 + 149<br>
&gt; 3. starting 40Mhz GO<br>
<br>
</span>OK, this is quite a special use case compared to 20/40 MHz co-ex<br>
operations with hostapd..<br>
<span class=""><br>
&gt; the current code will cause the GO to fail, as although we are connected to<br>
&gt; channel 149, the ap will be finally started on channel 153 due to bss<br>
&gt; overlap.<br>
&gt;<br>
&gt; it seems to me a bit weird to fail here (as we are already connected to an<br>
&gt; AP with the same control channel), but please tell if this is the expected<br>
&gt; behavior in such case :)<br>
<br>
</span>Strictly speaking, it looks like the IEEE Std 802.11-2012 co-ex rules<br>
would indeed force us to switch PRI/SEC channels in this case. If the<br>
driver does not support multi-channel concurrency, this would indeed<br>
result in HT40 setup failing. The options here would be to fall back to<br>
a 20 MHz BSS for the GO (which would be allowed on channel 149 in this<br>
case) or ignoring the &quot;shall&quot; requirement in the standard in a case<br>
where following it would be likely to cause more harm (which, I&#39;d<br>
expect, having to do multi-channel concurrency would indeed do).<br>
<br>
I think I&#39;ll make wpa_supplicant handle this special case by preventing<br>
PRI/SEC channel switch in case the local device already has another<br>
virtual interface operating (either in AP or STA mode) on the channel<br>
that is selected as the PRI channel for the new AP/GO interface. This<br>
won&#39;t change hostapd behavior and there is reasonable technical<br>
justification for the wpa_supplicant behavior due to concurrent<br>
operation.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div>sounds good.</div><div><br></div><div>thanks,</div><div>Eliad. </div></div></div></div>