Re: [PATCH 1/2] cfg80211: Support for automatic channel selection in AP mode

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2012-06-21 at 08:21 +0200, Michal Kazior wrote:

> > The reason I'm talking about this is the channel concurrency framework
> > that Michal is working on, which would conflict somehow with this I
> > think.
> 
> Hmm.. we should be able to deal with it. I have a couple of ideas:
> 
>   a) treat ACS AP as a non-fixed channel IBSS (i.e. reserve a single
>      channel resource); once channel notifications comes in we'd drop
>      the behaviour
> 
>   b) trust the driver it won't do anything funny (we already trust it
>      with channel switch notification)
> 
> 
> The a) requires more tricks to be done. Once we run out of channels to 
> run on we need to either:
> 
>   1) reject it and leave it to userspace to handle (i.e. retry .start_ap
>      without ACS)
> 
>   2) disable ACS implicitly and pick a channel ourselves (we'd need to
>      do a synthetic channel switch notification to userspace)
> 
>   3) extend ACS to accept channel list, so we could implicitly reduce it
>      to channels we're already on (probably involves some nice hackery)
> 

Seems tricky :-)

> The b) seems to have an issue. Consider the following scenario:
> 
>      [ no channels are used, max 1 channel concurrency, max 2 APs ]
>   1. wlan0: .start_ap with ACS
>      [ driver is starting ACS AP.. ]
>   2. wlan1: .start_ap on channel 1
>      [ the driver is probably locked right now
>        as it needs to complete (1); even if it's not locked
>        (1) probably can't be influenced by (2) anymore.
>        once it completes (1) it might end up on channel 6 on wlan0.
>        this means (2) fails kind of unexpectedly ]

I suspect that in this case the driver would have to fail the
second .start_ap though, since it's actually doing ACS at that time ...


johannes