Fast connect after losing Link

[Naveen Singh]

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.

With the current implementation I do not see any benefit of
wpas_supplicant trying to get connected on its own? Let me know what
you think?

Regards
Naveen