NetworkManager: A User's Review

Wed Apr 26 20:24:37 UTC 2006

On Wed, Apr 26, 2006 at 11:53:22AM -0400, Matthew Saltzman wrote:
> On Wed, 26 Apr 2006, Charles Curley wrote:
> 
> >What I do for wireless networking is a kludge of the first water.
> >
> >I use "service network restart" for my home network. It is set up with
> >WEP using 64 bit (10 hex digit) keys and does not broadcast its
> >SSID. I cannot access my home network with NetworkManager (hereafter
> >NM). However, I can use NM to get on a local open network. So I find
> >myself toggling between those two tools.
> 
> What do you have for a wirless card?  I don't have a problem accessing the
> hidden SSID at work (unless some student is in range with an ad-hoc 
> network with the same SSID).

Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)

It works just fine once it's set up, and both kwifimanager and kismet
detect the network.

This on a Lenovo R51. See: http://www.charlescurley.com/Lenovo.R51.html

> 
> >
> >NM's documentation is pathetic. Such documentation as exists is on the
> >NM web site, making it rather useless if you're trying to access the
> >net somewhere. (When else would the ordinary user care to see NM
> >documentation?)
> >
> >The prompts are useless to those who are not wireless network
> >gurus. To give a trivial example, when entering a WEP key as a hex
> >value, do I enter a leading 0x or not? Kwifimanager, by the way,
> 
> Not.  IIRC, Windows wirless manager doesn't need '0x' and doesn't tell you 
> it doesn't either.  A "wireless illiterate" wouldn't think to put in '0x' 
> anyway unless he was used to system-config-network.

A wireless illiterate familar with C coding practices might well think
of it. Which is indeed why I came up with it.

> 
> >qualifies WEP keys as you enter them, one keystroke at a time, so that
> >it is obvious when you have entered a valid key and when you have not.
> 
> Haven't used kwifimanager, but I'm not sure what you mean here.

If you have a valid key, text to the right of the entry widget
indciates that there is a valid 64 or 128 bit key in green
text. Otherwise it indicates invalidity in red text. It does this for
each keystroke you enter.

> 
> >
> >If the target user for NM is the wireless illiterate, the implementers
> >should design the prompts for the wireless illiterate, not for
> >themselves. The way to do this is get several wireless illiterates to
> >attempt to make multiple connections. Encourage the testers to ask
> >questions. The answer to each and every question the testers asks
> >should be put -- in simple language -- into the GUI where the user can
> >find it.
> >
> >NM makes no effort to preserve attempted logon data across tries. If
> >your attempt fails, and you want to try different things, you have to
> >stop the daemon, restart it, then retype everything, not just the
> >changes. This is the sort of inane user-hostile stupidity one expects
> >of a Vogon.
> 
> I've never had to stop and restart the daemon just to reenter logon data. 
> In fact, I wouldn't think it would help.  Once the data is in your config, 
> it doesn't go away when you restart.  Just select "connect to other 
> wireless network" and you get a fresh dialog.  I have had to restart the 
> daemon because buggy wireless drivers get hung up, but that's not the same 
> thing.

The first time I attempt a connection, I can use either "connect to
other" or "Create new". If I hit "connect to other", I get a popup
window for "Existing wireless network". Since my home network already
exists, that must be what I want, right? So I type in the name,
etc. and the attempt fails.

To me, creating a new network means starting a brand new network,
specifying how the encryption (if any) will work, and managing it on
the machine where I create the network. Or are we talking about
creating a new wireless network *connection*? Again, documentation
failure.

So now the network exists in the pulldown menu, and (since the attempt
failed) I should be able to change a parameter ot two. Wrong! I click
on it, and... nothing. The popup menu goes away, the "no connection"
icon stays there, and that's it.

Or, knowing that there is no ghod but Murphy, I try to create a new
network. Same useless results.

Of course, one problem might be that the AP says it's using 64 bit
keys, and NM seems to accept only 128 bit keys. Again, documentation
failure: how about saying something like, "Sorry, we don't work with
64 bit keys, only 128 bit keys."? Or, of course, try supporting
them. I have since changed the network to use a 128 bit key. It
doesn't help. NM inists that the network requires a password, which it
does not.

> 
> >
> >Because of these idiocies, I've given up trying to use NM on my home
> >network. NM is very nice when it works. You fire it up (you shouldn't
> >even have to do that; you should be able to leave it running), and it
> 
> # chkconfig NetworkManager on
> 
> Then it starts at boot and is always on.

I'm aware of that. But if I'm stuck using several tools for different
networks, I'll have the appropriate one running and leave the rest
shut down. Also, NM is hostile to kismet, another reason to shut it off.

> 
> >connects, even to a network it's never seen before. But when human
> >intervention is required (such as entering a WEP key), it is user
> >hostile to the point of uselessness.
> 
> If you'd like to see the tool improved (I don't want to appear to be 
> suggesting that your critique is baseless), you should really post to 
> networkmanager-list at gnome.org (subscribe at mail.gnome.org), where the 
> developers hang out.

I may yet.

-- 

Charles Curley                  /"\    ASCII Ribbon Campaign
Looking for fine software       \ /    Respect for open standards
and/or writing?                  X     No HTML/RTF in email
http://www.charlescurley.com    / \    No M$ Word docs in email

Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20060426/6c0f3e86/attachment-0001.sig>