Fast connect after losing Link

[Naveen Singh]

On Fri, Feb 5, 2016 at 11:39 AM, Jouni Malinen <j at w1.fi> wrote:
> On Wed, Feb 03, 2016 at 03:15:59PM -0800, Naveen Singh wrote:
>> I guess short amount of time is quite debatable. Just the wifi medium
>> access time could vary from  scenario to scenario. There are many
>> things that needs to be considered:
>>
>> 1) We need to notify connman that L2 level link is gone but
>> wpa_supplicant is trying to get connected back.
>
> Or alternatively not notify connman at all before wpa_supplicant has
> tried and failed to reconnect.. That said, I have no issues in adding a
> separate notification that makes it clear there is an attempt to
> reestablish connection to the same ESS as a noted that IP address etc.
> should not yet be dropped.

It makes sense. Do you think it would be better to generate both the
events the very first time (when wpa_s is trying to reestablish the
connection) and only the second event when it failed to reconnect.
This way existing devices which upgrades to new wpa_s but do not
upgrade their applications will not see any difference. Let me know
your thoughts.
>
>> 2) With this notification connman would let applications know that
>> data traffic is not feasible at this time but it is not a disconnect
>> notifications
>
> Does that capability exist today and how do applications use that
> information? I'm assuming this would leave the netdev with IP
> address(es) and routing in place.

Unfortunately it does not exist. I will have to work for this. It may
be tricky as everything would have to be handled from gsupplicant/wifi
plugin directory.
>
>> 3) When wpa_supplicant is done with all its attempt (including current
>> BSSID and any other BSSID), it does a final notification that
>> connection is lost
>
> All its attempts to _this ESS_. Yes, sounds fine to add such a
> notification.
>
>> 4) connman or user level application takes control from here.
>
> That depends on the use case.. If configured to do so with multiple
> enabled network profiles, wpa_supplicant will try to find another ESS as
> an alternative. Anyway, if connman does not want such behavior, it can
> enable only a single network profile.
>
>> So to make it robust I think we need two different notification and
>> that needs to be handled differently in connman.
>
> Agreed.
>
> --
> Jouni Malinen                                            PGP id EFC895FA

Regarding the implementation what do you propose? Do you want me to
add this event handling in the code and send a patch. I am not very
familiar with the black listing logic in wpa_s but if you want I can
take care of this. Let me know your thoughts.

Regards
Naveen