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. > 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. > 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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
