On Tue, Feb 9, 2016 at 3:13 PM, Naveen Singh <naveensingh0977@xxxxxxxxx> 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:
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
