Re: supplicant interface scan state tracking

[Witold Sowa <witold sowa gmail com>]

Witold Sowa pisze:
> Daniel Drake pisze:
>> On Tue, 2009-07-07 at 12:15 -0400, Dan Williams wrote:
>>   
>>> It could be a signal ordering issue.  The code in
>>> nm-supplicant-interface.c is:
>>>
>>> 	if (priv->scanning)
>>> 		return TRUE;
>>> 	if (priv->con_state == NM_SUPPLICANT_INTERFACE_CON_STATE_SCANNING)
>>> 		return TRUE;
>>>
>>> So only if both of these are FALSE will
>>> nm_supplicant_interface_get_scanning() return FALSE.  Each of these
>>> variables is independently set, priv->scanning is based off the
>>> supplicant's 'scanning' property, and priv->con_state is based off the
>>> 'state' property.
>>>     
>>
>> The problem is that sometimes when this happens, con_state is never
>> updated. It remains as SCANNING even after eth0 has been disconnected.
>> Would it be OK to reset this to 0 inside disconnect_cb?
>>
>> Daniel
>>   
> Mayby that's because in supplicant's wpa_supplicant_clear_status function (wpa_supplicant.c) state is changed to disconnected, but notification is not sent?
>
> Witek
>   
No, that's not a problem. Sorry for the false alarm. BTW: why we have
separate scanning property? Isn't status  == scanning enough?
>> _______________________________________________
>> NetworkManager-list mailing list
>> NetworkManager-list gnome org
>> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>>   
>