Re: supplicant interface scan state tracking

[Dan Williams <dcbw redhat com>]

On Tue, 2009-07-07 at 22:41 +0100, Daniel Drake wrote:
> 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?

No; because disconnect just terminates the current association, it
doesn't actually have any effect on the supplicant interface's state.
Just because we're disconnected doesn't mean we can't request scans or
whatever.

Is NM perhaps ignoring some other signal from the supplicant after
disconnect?  Or is the supplicant not sending state updates after a
disconnect?

Dan