On Fri, 2009-06-05 at 19:12 +0100, Daniel Drake wrote: > On Fri, 2009-06-05 at 09:16 -0400, Dan Williams wrote: > > How about using the 'scanning' property instead? That's exactly what > > the 'scanning' property is for, and connection-state doesn't always > > reflect when the supplicant is actually scanning (ie, it won't back down > > from CONNECTED -> SCANNING when it's associated but can't find the AP in > > an unsolicited scan list, but will direct-scan again anyway), which is > > why I added the 'scanning' property and associated patch to > > wpa_supplicant. Will that do what you need? > > I don't know. > > I need a "subscribable" way of monitoring "is this interface currently > scanning for networks." I found the function > nm_supplicant_interface_get_scanning() which reflects both the > "scanning" property (which is subscribable, great), and the > "connection-state" property (which only half exists). > > If I'm to believe the logic in that function, I need to subscribe to > both "scanning" and "connection-state". The function seems to suggest > that sometimes, priv->scanning will be FALSE even though the connection > state is NM_SUPPLICANT_INTERFACE_CON_STATE_SCANNING.
It really shouldn't; I was being conservative there. The 'scanning' property (assuming you have that supplicant patch which is now upstream and also available at [1]) should reflect the scanning state internally in the supplicant. If you want, I'll take a patch that makes the supplicant interface's 'scanning' property derived from both wpa_supplicant and the connection state, and then you could still just use g_signal_connect (sup_iface, "notify::scanning", G_CALLBACK (my_callback), my_data); Dan [1] http://cvs.fedoraproject.org/viewvc/rpms/wpa_supplicant/F-11/wpa_supplicant-0.6.8-scanning-property.patch?view=log _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
