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

[Dan Williams <dcbw redhat com>]

On Wed, 2009-01-14 at 11:46 -0800, Howard Chu wrote:
> Dan Williams wrote:
> > On Tue, 2009-01-13 at 14:28 -0800, Howard Chu wrote:
> >> 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?
> 
> It appears to take a large fraction of a second. This is on an HP dv5z laptop. 
> The problem is that when I'm operating at greater distances from my wifi 
> router, bandwidth is already reduced and spotty, any additional interruptions 
> are enough to tip it over the edge. E.g., trying to watch a video that's 
> streaming with a nominal bandwidth of 18Mbps ought to work fine on 802.11g, 
> most of the time. On the HP, the scans made the video glitch. On my older Asus 
> M6Ne laptop with Intel 2200 card, I never saw this issue. (And I can run both 
> laptops side by side to reproduce the glitch on the HP and not on the M6Ne.) 
> Removing the scans removed most of the glitches.
> 
> > 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.
> 
> I guess that might be an issue for some people who move around a lot while 
> connected. Hard to imagine. In my case, at home I have only one AP, so no 
> matter where I walk around the house, the topology is unchanged. Likewise at 
> my office. Surely it doesn't need to do a full scan to monitor the signal 
> strength of the AP it's talking to...
> 
> As for reconnection - as I said, scanning should be disabled while connected. 
> If the connection is lost and a reconnect is needed, then of course you have 
> no choice but to scan again.

Scanning cannot be disabled while connected, because by the time you get
a disconnect, that's *exactly* when you need the scan results to be able
to quickly reconnect to something.  Furthermore, if scanning is
disabled, the dropdown menu of wireless networks is useless because
there will only be one item in it, your currently connected AP.

Dan

> > 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.
> 
> Admittedly, the ath9k driver looks like it still needs work. I refresh my 
> driver from the wireless-testing repository every couple of weeks though, and 
> it's still an issue.
>