[PATCH 1/9] ap: switch pri/sec channels only if pri channel is idle

[Jouni Malinen]

On Sun, Jun 21, 2015 at 11:56:23AM +0300, Eliad Peller wrote:
> anyway, the actual problem we encountered was when working with
> single-channel device, and having the following environment:
> 1. connect to 20mhz ap on channel 149
> 2. having another 40mhz ap on channels 153 + 149
> 3. starting 40Mhz GO

OK, this is quite a special use case compared to 20/40 MHz co-ex
operations with hostapd..

> 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.
> 
> 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 :)

Strictly speaking, it looks like the IEEE Std 802.11-2012 co-ex rules
would indeed force us to switch PRI/SEC channels in this case. If the
driver does not support multi-channel concurrency, this would indeed
result in HT40 setup failing. The options here would be to fall back to
a 20 MHz BSS for the GO (which would be allowed on channel 149 in this
case) or ignoring the "shall" requirement in the standard in a case
where following it would be likely to cause more harm (which, I'd
expect, having to do multi-channel concurrency would indeed do).

I think I'll make wpa_supplicant handle this special case by preventing
PRI/SEC channel switch in case the local device already has another
virtual interface operating (either in AP or STA mode) on the channel
that is selected as the PRI channel for the new AP/GO interface. This
won't change hostapd behavior and there is reasonable technical
justification for the wpa_supplicant behavior due to concurrent
operation.

-- 
Jouni Malinen                                            PGP id EFC895FA