Fast connect after losing Link

[Dan Williams]

On Wed, 2016-02-03 at 12:33 -0800, Naveen Singh wrote:
> On Wed, Feb 3, 2016 at 8:56 AM, Naveen Singh <naveen at nestlabs.com>
> wrote:
> > 
> > 
> > On Wed, Feb 3, 2016 at 4:16 AM, Jouni Malinen <j at w1.fi> 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 at lists.infradead.org
> > > 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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap