Fast connect after losing Link

Naveen Singh naveensingh0977 at gmail.com
Tue Feb 16 13:24:02 PST 2016 

On Sat, Feb 13, 2016 at 9:48 AM, Adam Moore
<adam.moore at savantsystems.com> wrote:
> 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 all 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.
>

Hi Adam
Yes I am about to submit a patch to connman which does not disable the
network on disconnect notification. So the goal would be to not
interfere in the L2 level roaming decision of wpa_supplicant.
Supplicant would still generate disconnect notification and we will
tear down IP address. Earlier i was a big proponent of retaining the
IP address but conservatively speaking it is better to let the current
IP go. On the next connection, we will get a new IP. This would
probably solve the case of houses where people have multiple AP in
home and each one is acting like a DHCP server. Renewing the lease
would probably be the right thing to do.

Regards
Naveen

More information about the Hostap mailing list