Re: Prevent auto scan in wireless devices (Aloisio Almeida)

[Dan Williams <dcbw redhat com>]

On Tue, 2009-01-13 at 14:28 -0800, Howard Chu wrote:
> > Date: Tue, 13 Jan 2009 17:45:16 -0300
> > From: Aloisio Almeida<aloisio almeida openbossa org>
> 
> > Hi all,
> >
> > I noticed that wireless devices are always scanning, and this is very
> > bad to power consuption in embedded systems.
> > I would like to create a way to prevent automatic scan and just
> > perform it when some cliente ask for it.
> > Is it possible to do this? I mean, does it "brake" in some way the nm structure?
> >
> > Actually, I already did this patch to 0.6.6 version, but zero lines
> > applied in new code :) Now i would like to create the patch and submit
> > to upstream.
> >
> > The basic idea is just make can_scan function (src/nm-device-wifi.c)
> > return FALSE due to some user configurations or run flags
> > (--no-bg-scan). In this case, "performScan" dbus method and
> > "ScanPerformed" dbus signal must be created to allow clients to ask
> > for a scan and to notice that the scan has been performed.
> >
> > I'm attaching the 0.6.6 patch, as I said before the idea is the same.
> >
> > Any comments? Is it a good way to implement that?
> 
> I also noticed that in NM 0.7 prereleases, scans did not occur on my ath9k 
> when it was associated, but after 0.7 was released, this behavior changed. (I 
> found the commit that changed this, saying it was removing a hack...) I 
> reinstated the hack on my build, because it was disrupting my streaming wifi 
> traffic. All in all, I would love to see scans only occurring on demand, and 
> not at any other time.

How long does the scan take on your ath9k card, and does buffering not
paper over any momentary hiccups?  Also, is your machine a desktop
machine or laptop?  Not scanning periodically means that NM (and the
supplicant, and the driver) doesn't have a good picture of the network
topology, and this can have adverse consequences for roaming and
reconnection.  If the driver is taking a long time to scan, then the
driver may need some optimizations as well.  The hack was there because
long ago, madwifi simply couldn't scan in a reasonable amount of time.
These days, almost all cards/drivers can scan in a reasonable amount of
time, and those with hardware assisted scanning like Intel cards can do
it even faster.

Dan