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

[Eliad Peller]

hi Jouni,

On Fri, Jun 19, 2015 at 3:48 PM, Jouni Malinen <j at w1.fi> wrote:

> On Wed, Jun 17, 2015 at 04:18:13PM +0300, Ilan Peer wrote:
> > IEEE Std 802.11-2012 (10.15.3.2) states that the secondary
> > channel should be a channel with no other beacons, unless
> > beacons are detected on both the primary and secondary
> > channels.
>
> Yes and just before that it states that the PRI/SEC channels shall be
> identical with a detected BSS unless there is already mix of different
> PRI/SEC channels which is an actual requirements (shall vs. should).
>
> right. i probably attributed the behavior to the wrong paragraph.

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

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

> The current code doesn't check the existence of such
> > beacons, resulting in unnecessary switch in case
> > of HT20 ap on our primary channel + overlapping HT40 ap.
>
> There is already a check for whether beacons are detected on SEC
> channel, but not on PRI and switches own configuration based on that.
> Could you please provide a more detailed example of this? I'd like to
> see the list of detected PRI/SEC channels and the local configuration in
> which case the unnecessary switch happens.
>
> > Add check to consider this switch only if there are
> > no beacons on the primary channel.
>
> I'm not sure I follow the logic here taken into account !pri_bss
> condition here would imply that sec_bss == 0, i.e., the earlier loop
> through scan results did not find a single BSS on either our PRI or SEC
> channels. How could this second loop find a match in such a case?
>
> you're right, i overlooked it.

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