Re: supplicant interface scan state tracking

[Dan Williams <dcbw redhat com>]

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