Question on commit: "Do not inform other virtual interfaces of scan results in all cases"

[Ben Greear]

On 06/01/2014 01:39 AM, Jouni Malinen wrote:
> On Mon, May 12, 2014 at 08:04:35AM -0700, Ben Greear wrote:
>> I have been trying to figure out why my multi-vif associations are taking too long,
>> and it seems to be caused by this patch below.
>>
>> In my case, I very much want to do multiple associations at a time.
>>
>> So, question is:  Why was this considered harmful?  Maybe the problem
>> only happens if two vifs are on different channels, or something like that?
>
> I don't remember the exact issue that triggered this, but I think it was
> based on a debug log that showed a concurrent P2P operation and a
> non-P2P station interface trying to connect at the same time and one of
> the operations either failing completely or at least delayed
> significantly because of the steps that require exclusive radio control
> (channel) being executed at the same time.
>
> If I understood your later emails correctly, you have a configurable
> parameter to allow these types of operations to occur at the same time.
> That may be the safest options since it is clear that there are drivers
> that issues with this. While different channels make this worse, I'm not
> sure that is the only issue, i.e., just getting those commands for
> different virtual interfaces may be enough to break (or at least block)
> things.

I found that ath10k has issues with associating stations too rapidly
and I have not looked at why yet.

ath9k works great with lots of stations associating concurrently (on the same
channel, at least).

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com