On Wed, Feb 3, 2016 at 3:05 PM, Dan Williams <dcbw@xxxxxxxxxx> wrote: > On Wed, 2016-02-03 at 14:55 -0800, Naveen Singh wrote: >> On Wed, Feb 3, 2016 at 12:46 PM, Dan Williams <dcbw@xxxxxxxxxx> >> wrote: >> > On Wed, 2016-02-03 at 12:33 -0800, Naveen Singh wrote: >> > > On Wed, Feb 3, 2016 at 8:56 AM, Naveen Singh <naveen@xxxxxxxxxxxx >> > > > >> > > wrote: >> > > > >> > > > >> > > > On Wed, Feb 3, 2016 at 4:16 AM, Jouni Malinen <j@xxxxx> wrote: >> > > > > >> > > > > On Tue, Feb 02, 2016 at 11:56:09PM -0800, Naveen Singh wrote: >> > > > > > Just after losing wifi link because of an incoming deauth >> > > > > > with >> > > > > > reason >> > > > > > code 6 or 7, wpa_supplicant sets the fast_reconnect and >> > > > > > fast_reconnect_ssid to current bss and current ssid. >> > > > > > >> > > > > > Later on if fast_reconnect is not NULL it tries to connect >> > > > > > to >> > > > > > same >> > > > > > SSID. This makes sense for some devices which does not use >> > > > > > connman. >> > > > > > Devices using wpa_supplicant with connman this connect is >> > > > > > not >> > > > > > useful >> > > > > > at all as connman when it gets notified of this disconnect >> > > > > > would >> > > > > > disable the network that would end up causing a locally >> > > > > > generated >> > > > > > deauth and would nullify this connection attempt. >> > > > > >> > > > > Why would connman do something like that? Large number of >> > > > > enterprise APs >> > > > > use Deauthentication frames to force load balancing and/or >> > > > > band >> > > > > steering. Disabling the network profile immediately on a >> > > > > disconnection >> > > > > event sounds like something that would result in pretty bad >> > > > > user >> > > > > experience in such networks. >> > > > >> > > > Agreed. And we are seeing this. >> > > > > >> > > > > >> > > > > > In stead of having this feature turned on all the time, it >> > > > > > would be >> > > > > > good to have a configuration from connman. Initialized >> > > > > > value of >> > > > > > this >> > > > > > configuration would be turned on meaning fast connect is >> > > > > > enabled and >> > > > > > devices using connman along with wpa_supplicant would >> > > > > > disable >> > > > > > this >> > > > > > feature. >> > > > > > >> > > > > > Does this make sense? >> > > > > >> > > > > If I understood the issue correctly, it sounds like the >> > > > > better >> > > > > direction >> > > > > would be to modify connman.. >> > > > > >> > > > > -- >> > > > > Jouni Malinen PGP >> > > > > id >> > > > > EFC895FA >> > > > > >> > > > > _______________________________________________ >> > > > > Hostap mailing list >> > > > > Hostap@xxxxxxxxxxxxxxxxxxx >> > > > > http://lists.infradead.org/mailman/listinfo/hostap >> > > > >> > > > >> > > Hi Jouni >> > > I was looking into the code for fast_connect from >> > > wpa_supplicant_event_disassoc_finish and it looks like we try to >> > > connect to same BSS. If it is trying to connect to same BSS how >> > > does >> > > it helping us in solving band steering or load balancing problem. >> > > If >> > > the connect request is invoked from >> > > wpas_select_network_from_last_scan >> > > we may have a different BSSID and then I can understand it is >> > > trying >> > > to connect to a different BSSID. Am I missing something here? >> > >> > I think his point is that if connman disables the entire network >> > block >> > when it gets a deauth, that prevents reconnection to a *different* >> > BSS >> > in the same SSID. Since connman doesn't appear to lock the network >> > block to a single BSSID, this would indeed prevent the supplicant >> > from >> > reconnecting to the SSID quickly, whether to the same AP as before >> > or a >> > different one. >> > >> > Dan >> > >> > > if (fast_reconnect) { >> > > #ifndef CONFIG_NO_SCAN_PROCESSING >> > > wpa_dbg(wpa_s, MSG_DEBUG, "Try to reconnect to the same BSS"); >> > > if (wpa_supplicant_connect(wpa_s, fast_reconnect, >> > > fast_reconnect_ssid) < 0) { >> > > /* Recover through full scan */ >> > > wpa_supplicant_req_scan(wpa_s, 0, 100000); >> > > } >> > > #endif /* CONFIG_NO_SCAN_PROCESSING */ >> > > } >> > > >> > > Regards >> > > Naveen >> > > >> > > _______________________________________________ >> > > Hostap mailing list >> > > Hostap@xxxxxxxxxxxxxxxxxxx >> > > http://lists.infradead.org/mailman/listinfo/hostap >> >> Hi Dan >> >> connman code currently disables the network on the disconnect >> notification and then wpa_supplicant code re-enables the network as a >> part of SelectNetwork DBUS method call handling. >> >> I am not sure with current set of API between connman and >> wpa_supplicant how much of a fast roaming really holds value. >> wpa_supplicant indicates disconnect notification to connman and then >> tries to re-establish wifi connection (either to same BSSID or a >> different BSSID in the same network). Now connman once it gets the >> disconnect notification will tear down L3 link (release IP address, >> deletes all the route etc). So even if wpa_supplicant gets you >> connected to an AP, this connection is of no use. >> >> Should not be in this case either wpa_supplicant should not indicate >> disconnect notification after it has exhausted its retries to get >> device connected to wifi or should use a different method to >> communicate to connman so that connman will not proceed tearing down >> link. > > Or, connman doesn't tear down the L3 connection immediately on > disconnect, but instead waits a short period of time for the supplicant > to reconnect, and only if that time elapses does it tear down the L3 > connection. There are many reasons why disconnects happen and some of > those reasons are transient and recoverable, and the L3 address can be > preserved across the reconnect. > > Dan 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. 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 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 4) connman or user level application takes control from here. So to make it robust I think we need two different notification and that needs to be handled differently in connman. Regards _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
