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

[Eliad Peller]

On Sun, Jun 28, 2015 at 6:24 PM, Jouni Malinen <j at w1.fi> wrote:

> 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.
>
> sounds good.

thanks,
Eliad.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20150701/83862d76/attachment.htm>