On Wed, 2009-07-08 at 01:28 +0200, Witold Sowa wrote: > 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?
No, because when the card is already in CONNECTED state, the supplicant purposefully doesn't flip back to SCANNING when a scan request comes in (like when NM requests a periodic scan). It also won't flip to SCANNING when unsolicited results come in and the supplicant can't find the associated AP, which makes the supplicant perform an additional specific-SSID scan for the associated AP. I don't really think that's a huge problem; the "state" is an overall state and doesn't actually reflect periodic scans while associated, because you're still associated. Dan _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list