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 >> >
_______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list