Roaming and radio-work concurrency.

[Ben Greear]

On 06/16/2014 02:33 PM, Jouni Malinen wrote:
> On Tue, Jun 10, 2014 at 02:13:10PM -0700, Ben Greear wrote:
>> In older code, we could have one supplicant managing many station
>> vifs and use wpa_cli to ask supplicant to roam them concurrently...
>>
>> With latest code, the radio-work logic serializes the roam
>> attempts.
>>
>> I need to fix this to allow concurrent roams...
> 
> I would use a different verb here taken into account that the radio work
> serialization is done by design to avoid issues with concurrent
> operations that require exclusive control of the radio channel on a
> single radio. Optimizing this to handle some cases more efficiently
> would be possible and I have that on my to-do list as well (though, not
> with very high priority).
> 
>> I have have not looked at the code in detail yet, but
>> I think I will need to either add a new option to the
>> wpa_cli roam command, or more likely, add something to
>> the supplicant config file to tell supplicant that concurrent
>> connects are OK.
> 
> I would not do that as a general "concurrent fine" yes/no..
> 
>> Any opinion on the 'right' way to go about allowing
>> concurrent associations?
> 
> The to-do item I have listed is to optimize radio work design to allow
> operations on a single channel to be performed in parallel. That should
> work for multiple different use cases. I'm thinking mainly of GAS/ANQP
> with multiple APs, but I'd expect this to help with your use case as
> well (I'm assuming you are thinking of the case of connecting to the
> same AP from multiple vifs). In other words, if you find a way of
> allowing multiple radio work items to be started concurrently with the
> constraint of them being for a single channel (wpa_radio_work::freq != 0
> and matches between the other items to be started), that could be useful
> for number of other cases as well.


Yes, that is what I want to accomplish.  Are you ok with just allowing this
always, or do you want a configurable to keep the current behaviour as an
option?

Thanks,
Ben

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