Re: NMDeviceWifi "scanning" notifier inaccurate

[Dan Williams <dcbw redhat com>]

On Fri, 2010-07-09 at 15:58 -0600, Daniel Drake wrote:
> Hi Dan,
> 
> I finally got round to investigating this issue:
> http://thread.gmane.org/gmane.linux.network.networkmanager.devel/13607
> 
> To summarize, notifications of the "scanning" property of NMDeviceWifi
> are not always generated when reading this value would in fact produce
> a different value from before.
> 
> This property is implemented as a call to
> nm_supplicant_interface_get_scanning() which is implemented as "return
> TRUE if the supplicant state is scanning, or if the supplicant
> asserted the flag saying that scanning is in-progress"
> 
> When the supplicant asserts/deasserts the "scanning" flag, we
> correctly arrive in supplicant_iface_notify_scanning_cb() which
> generates a notification on the property. The bug is that NMDeviceWifi
> doesn't watch for relevant changes in the supplicant state to generate
> the notification in the other cases when this property can change
> value.
> 
> The bug I'm seeing is:
> 1. eth0 is scanning, so the supplicant state is: scanning=1 state=scanning
> 
> 2. I activate a connection on msh0. real_act_stage1_prepare() in the
> mesh device realizes that the companion is scanning so it returns
> NM_ACT_STAGE_RETURN_POSTPONE
> The driver is listening for changes in the NMDeviceWifi scanning
> property so that it can continue the state progression of msh0.
> 
> 3. supplicant state changes to: scanning=0 state=scanning
> The "notify" event is generated on NMDeviceWifi but the scanning
> property still reads false so nothing interesting happens.
> 
> 4. supplicant state changse to: scanning=0 state=disconnected
> At this point no notify event is generated, but it should be, because
> reading NMDeviceWifi's scanning property will now finally read FALSE.
> 
> 
> I'm attaching a patch that fixes the issue. It will generate a few
> more notify events than needed (i.e. it will sometimes notify when no
> property change happened) but I can't think of a nice way to make this
> more accurate. What do you think?

Pushed on 0.7.x, 0.8.x, and master.

Dan