Re: NM refresh list issues

[Dan Williams <dcbw redhat com>]

On Thu, 2010-07-15 at 14:04 -0600, Matt Warnock wrote:
> Hi all:
> 
> I'm running NM 0.8 on a Dell Studio 1555 Laptop with Ubuntu 10.04, using
> the Broadcom STA wireless driver.  I regularly run between home and the
> office. I usually don't hibernate, I just suspend by closing the lid and
> go, and reopen the lid when I get to the  other location.  When I get
> there, invariably the list of WIFI networks displayed by left-clicking
> the NM icon is the OLD list.  The only way I can get it to refresh to
> the networks in the NEW location is to disable WIFI, re-enable it, and
> (usually) manually select the new network, which should be automatic,
> but usually isn't, for whatever reason.  This could be a Broadcom driver
> issue, but I doubt it, because a prior Toshiba laptop has similar
> issues.

To isolate the issue, try running this command periodically in a root
terminal:

iwlist <wifi interface name> scan

and see what it says.  If you periodically get failures, then NM is
probably also encountering those same driver failures when scanning.

NM scans on a timer that maxes out at every 2 minutes, and APs are kept
in the scan list for up to 6 minutes.  If the AP hasn't been found in a
scan in the last 4 - 6 minutes or so, then it will drop out of the list.
It *should* drop out of the list even if there are scan failures too.

> I asked this question previously, but at that time the problems were
> attributed to a known bug with suspend possibly affecting upgrades to
> Ubuntu from prior versions, and also possibly 64-bit Ubuntu (which I was
> running before).  
> 
> Since then I have downgraded to i386 (to solve flash video problems with
> 64-bit Ubuntu) and have done a fresh install from scratch.  I still have
> the same issues.  So here are the questions:
> 
> 1) I understand (from discussion on this list) that NM only refreshes
> its network list every 2-5 minutes.  This seems unreasonably slow to me,
> especially when the connected AP is *no longer* connected.  Does
> searching for networks draw additional power (seems like a receive-only
> function to me) or significant CPU bandwidth?  Is there some reason it

No, it really doesn't do either.  The impact on laptops is quite
minimal.

> doesn't search and update this list more often, say every 30-60 seconds?
> The Wiki says only that NM attempts to scan "in a manner that impacts
> the card the most", whatever that means.

It *does* decrease responsiveness of streaming connections, like SSH,
streaming music/movies, or VOIP though.  We don't want to be doing it
too often.  Hence why it's not done every 30 - 60 seconds.

> 2) I know suspend/hibernate is tricky, all the more reason it should NOT
> be relied on to operate properly in all cases.  But if a connection is
> lost (regardless of suspend/hibernate status), should that not again
> trigger an immediate search for networks?  If the connection to the
> current AP is lost, then obviously the environment has changed.  Maybe
> one preferred access point has gone down, but maybe a backup hub is
> available. Or maybe the laptop has moved. Should NM not automatically
> refresh the list, and try to connect to another available auto access

wpa_supplicant will often trigger rescans underneath NM as well,
especially when connections are lost and the AP is no longer found.  The
results of this scan are also consumed by NM.  So in many cases it's
already doing a rescan when the connection is dropped.

> point?  By the same token, if if finds *NO* Wifi networks (like driving
> through Nevada, or the manual WIFI switch is off) or no *previously
> used* networks (like in a new hotel room), it could shut the receiver
> down and only power it up to rescan every 5-15 minutes to save battery,
> or even less frequently.  But it's first reaction on losing a connection
> SHOULD be to look for another.
> 
> 3) In the interest of user-friendliness, should there not be an option
> to immediately "refresh available networks list" on the main menu?

There's a fair amount of previous posting on this.  I'd rather do the
"continuous scan" thing when UI is active and refresh the list in-place.
That's something that's not exactly possible with the current Gnome
applet but that shouldn't block other desktops (ie KDE) from doing that.
We've got various plans to fix this.

The point being that adding more buttons is rarely the right behavior,
you need to look for more seamless solutions like continuous scan when
UI is active instead of cluttering up the UI.  But yes, it could be
friendlier.

> Having to disable/enable WIFI to effect this refresh of the network list
> is both counter-intuitive to new users and extra work for everybody.  In
> the Wiki, it says that "clicking on the applet will initiate a scan
> request."  Either that does not work, or the list is displayed before
> the scan is complete (I don't know how long a scan takes, seconds?
> less?), otherwise I would not see old info displayed as I always do.
> Even if the claimed action in the Wiki were true, it would be bad
> interface design and counter-intuitive, unless it also displayed a
> "searching" dialog until the list is refreshed, or refused to display a
> list that is not confirmed by the current scan.  Then people would know
> for sure that a real and current scan is actually happening, and not
> just displaying cached data, which is apparently happening now.
> 
> 4) The relationship between the various connections listed in "edit
> connections" is anything but clear.  Is there a priority in which "auto"
> connections are tried (Wiki says the last WIFI used is first, but what
> order after that?)  Is a wired connection always preferred over a Wifi,

The last connected network is tried first, assuming it has been found by
your wifi card.  When you have a cable *and* wifi connected, they are
both active, but the ethernet gets the default route.

> over a broadband, etc?  Are there ways to adjust those preferences or
> priorities?  A help button here would go a long way, since the man pages
> for "networkmanager" and "nm-tool" leave much to be desired. And since
> NM is the way we GET to the net, a URL on the "about" page is no
> substitute for a little internal/local documentation somewhere.   

This is true.

> It seems to me that in the interest of making networking "just work", NM
> needs to take more of a "belt-and-suspenders" approach-- rather than
> just assume that the intended functionality is always working, it needs
> ways that the user can gently "nudge" or confirm it when it isn't. 
> 
> Sorry if this sounds like a rant-- it really is intended to be
> constructive.  I appreciate all you have done to date-- I just wish NM
> delivered a little better on its promise of "just working".  

Nope, it certainly is constructive.  And we need to do better here.

Dan