Fast connect after losing Link

[Naveen Singh]

On Wed, Feb 3, 2016 at 3:05 PM, Dan Williams <dcbw at redhat.com> 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 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

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