Fast connect after losing Link

[Adam Moore]

Hey Naveen,

On 2/12/16, 12:17 PM, "Hostap on behalf of Naveen Singh"
<hostap-bounces at lists.infradead.org on behalf of
naveensingh0977 at gmail.com> wrote:

>Hi
>
>On Fri, Feb 12, 2016 at 7:50 AM, Dan Williams <dcbw at redhat.com> wrote:
>> On Thu, 2016-02-11 at 19:06 -0800, Naveen Singh wrote:
>>> On Tue, Feb 9, 2016 at 3:13 PM, Naveen Singh <naveensingh0977 at gmail.c
>>> om> wrote:
>>> > On Fri, Feb 5, 2016 at 11:39 AM, Jouni Malinen <j at w1.fi> wrote:
>>> > > On Wed, Feb 03, 2016 at 03:15:59PM -0800, Naveen Singh wrote:
>>> > > > 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.
>>> > >
>>> > > Or alternatively not notify connman at all before wpa_supplicant
>>> > > has
>>> > > tried and failed to reconnect.. That said, I have no issues in
>>> > > adding a
>>> > > separate notification that makes it clear there is an attempt to
>>> > > reestablish connection to the same ESS as a noted that IP address
>>> > > etc.
>>> > > should not yet be dropped.
>>> >
>>> > It makes sense. Do you think it would be better to generate both
>>> > the
>>> > events the very first time (when wpa_s is trying to reestablish the
>>> > connection) and only the second event when it failed to reconnect.
>>> > This way existing devices which upgrades to new wpa_s but do not
>>> > upgrade their applications will not see any difference. Let me know
>>> > your thoughts.
>>> > >
>>> > > > 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
>>> > >
>>> > > Does that capability exist today and how do applications use that
>>> > > information? I'm assuming this would leave the netdev with IP
>>> > > address(es) and routing in place.
>>> >
>>> > Unfortunately it does not exist. I will have to work for this. It
>>> > may
>>> > be tricky as everything would have to be handled from
>>> > gsupplicant/wifi
>>> > plugin directory.
>>> > >
>>> > > > 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
>>> > >
>>> > > All its attempts to _this ESS_. Yes, sounds fine to add such a
>>> > > notification.
>>> > >
>>> > > > 4) connman or user level application takes control from here.
>>> > >
>>> > > That depends on the use case.. If configured to do so with
>>> > > multiple
>>> > > enabled network profiles, wpa_supplicant will try to find another
>>> > > ESS as
>>> > > an alternative. Anyway, if connman does not want such behavior,
>>> > > it can
>>> > > enable only a single network profile.
>>> > >
>>> > > > So to make it robust I think we need two different notification
>>> > > > and
>>> > > > that needs to be handled differently in connman.
>>> > >
>>> > > Agreed.
>>> > >
>>> > > --
>>> > > Jouni Malinen                                            PGP id
>>> > > EFC895FA
>>> >
>>> > Regarding the implementation what do you propose? Do you want me to
>>> > add this event handling in the code and send a patch. I am not very
>>> > familiar with the black listing logic in wpa_s but if you want I
>>> > can
>>> > take care of this. Let me know your thoughts.
>>> >
>>> > Regards
>>> > Naveen
>>>
>>>
>>> I think we may not need any new event to convey whether wpa_s is
>>> trying to get connected to one of the BSS in ESS or has attempted
>>> every BSS in that ESS. In current code when client gets
>>> deauthenticated or disassociated
>>> "wpa_supplicant_event_disassoc_finish" is called.
>>> "wpa_supplicant_event_disassoc_finish" ends up calling
>>> "wpa_supplicant_mark_disassoc" which calls
>>> "wpa_supplicant_set_state(wpa_s, WPA_DISCONNECTED)" .
>>> wpa_supplicant_set_state will end up generating the DBUS property
>>> change event for "State". Connman works on this event and considers
>>> this as disconnected notification and tries to disable the network
>>> which ends up interfering with supplicant selection logic of the
>>> correct BSS.
>>>
>>> But in reality it is indeed not disconnected because supplicant is
>>> actually going to attempt to get device connected back. So the state
>>> should be WPA_ASSOCIATING. If we do a state transition to
>>> WPA_ASSOCIATING instead of WPA_DISCONNECTED, connman would handle
>>> this
>>> event differently and do not attempt to disable the network or try to
>>> connect the network on its own.
>>>
>>> So what I was proposing that when we call
>>> wpa_supplicant_mark_disassoc
>>> from wpa_supplicant_event_disassoc_finish function we pass another
>>> argument as state and make that as WPA_ASSOCIATING. Something like
>>> this:
>>
>> I don't think that works either, unfortunately.  There's no way to know
>> if the ASSOCIATING state is appropriate or not because at this point,
>> the supplicant doesn't know if it will immediately begin associating
>> with an AP or if there are no available APs.
>>
>> The more I think about this, the more I think Connman just has its idea
>> of disconnection wrong.  The supplicant defines the DISCONNECTED state
>> as being disconnected from any AP but still attempting to find an AP to
>> associate with.  Even if all APs have been blacklisted, the supplicant
>> will eventually clear the blacklist and try to associate to the SSID
>> again.  Since Connman only sends one network block, you know exactly
>> which SSID it will attempt to associate with.
>>
>> When L2 drops the supplicant will attempt to reconnect only to the SSID
>> of the enabled network block sent by Connman. When the supplicant
>> enters the DISCONNECTED state from a previously-connected state,
>> Connman could start a short timer (15 or 20 seconds?) and wait for the
>> ASSOCIATING state to happen.  If the supplicant does begin associating
>> that's great, wait for COMPLETED and leave L3 up and running.  But if
>> the timer expires, it's likely the supplicant doesn't have anything to
>> connect to, and L3 can be torn down.
>>
>> Does that seem like reasonable behavior?  I think the supplicant's
>> behavior is currently sufficient for the problem you describe, just
>> that Connman's interpretation of that behavior is somewhat wrong.
>>
>> Dan
>>
>>> static void wpa_supplicant_event_disassoc_finish(struct
>>> wpa_supplicant
>>> *wpa_s, u16 reason_code, int locally_generated)
>>> {
>>>      //existing piece of code
>>>      wpa_supplicant_mark_disassoc(wpa_s, WPA_ASSOCIATING);
>>>
>>>
>>>
>>> }
>>>
>>> void wpa_supplicant_mark_disassoc(struct wpa_supplicant *wpa_s, int
>>> state)
>>> {
>>> //existing piece of cide
>>> wpa_supplicant_set_state(wpa_s, state);
>>> }
>>>
>>> Does this sound logical or we see any issue over here?
>>>
>>> Regards
>>> Naveen
>>>
>>> _______________________________________________
>>> Hostap mailing list
>>> Hostap at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/hostap
>
>Connman only operates on SSID level. All its API (whether AddNetwork,
>RemoveNetwork, Disconnect etc) all are for SSID. So connman treats the
>disconnect notification as a disconnect from a SSID which I guess is a
>fair assumption (going by the logic of symmetric API).
>
>I agree that changing the state to association is not a good idea for
>the reason you mentioned. I think the right way would be to either
>have two events as agreed with Jouni or having wpa_s not notify
>connman at all till it has tried all the BSSID of a specific ESS.


Thanks very much for looking into these issues - I am wrestling with
problems like these too (slow reconnects or no reconnects, especially in
high interference areas). However, I’m working on a headless device which
will always be configured to a single network. I’m encouraged by your
observation that removing the network disable code in connman greatly
improves your reconnect time. I would love to see that become a permanent
change if there is only a single favorite network in Connman in order to
give those devices the same reconnect speed as if they were just using
supplicant.

I¹m still very much a student of supplicant and connman, but regarding the
question of when Connman should decide to abandon the current ESS or radio
technology, I¹m nervous about delaying DISCONNECTED, as I agree it is
important to indicate an L2 drop or transition regardless of how temporary
it is. I also don¹t think the event should continue to be an indication
that Connman should immediately give up on the ESS, as giving supplicant a
shot at changing BSS within the ESS may minimize disruption, even if there
is a slightly better network available.

The task of deciding when to make a switch seems ideally suited for
Connman by leveraging the data it exclusively holds regarding
available radios, active sessions, configured networks and their signal
strengths, and user preferences.  Detailed disconnect or recovery state
may be relatively insignificant compared to Connman's data once it is put
to use, but it probably wouldn¹t hurt to expose some of that.  Deauth
reason codes may be particularly useful at higher layers.

Cheers,
-Adam


>
>Regards
>Naveen
>
>_______________________________________________
>Hostap mailing list
>Hostap at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/hostap


Statement of Confidentiality

The contents of this e-mail message and any attachments are confidential and are intended solely for the addressee. The information may also be legally privileged. This transmission is sent in trust, and the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail or at 508.683.2500 and delete this message and its attachments, if any.