Fast connect after losing Link

[Dan Williams]

On Wed, 2016-02-03 at 14:55 -0800, Naveen Singh wrote:
> On Wed, Feb 3, 2016 at 12:46 PM, Dan Williams <dcbw at redhat.com>
> 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 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
> 
> 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