Hi
On Fri, Feb 12, 2016 at 7:50 AM, Dan Williams <dcbw@xxxxxxxxxx> 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@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
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.
Regards
Naveen
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
