On Fri, Feb 5, 2016 at 11:39 AM, Jouni Malinen <j@xxxxx> 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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
