Roaming and radio-work concurrency.

[Jouni Malinen]

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.

-- 
Jouni Malinen                                            PGP id EFC895FA