On Thu, 2016-02-11 at 19:06 -0800, Naveen Singh wrote:
> On Tue, Feb 9, 2016 at 3:13 PM, Naveen Singh <naveensingh0977@gmail.c
> om> wrote:
> > On Fri, Feb 5, 2016 at 11:39 AM, Jouni Malinen <j@xxxxx> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/hostap
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
