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