Re: network profiles

[Dan Williams <dcbw redhat com>]

On Tue, 2004-12-14 at 09:21 -0500, Bill Moss wrote:
> I started a laptop program at my university and for the last few years 
> have written a series of articles on how to set up Redhat and now Fedora 
> Core on them. Since most of the students still use Windows XP so I have 
> written about dual booting and made comparison's.
> 
> On the Windows XP side I consider the IBM Access Connections (IAC) 
> utility to be the gold standard for NetworkManager type utilities. IAC 
> maintains its own internal database of network profiles that contain

One thing I specifically tried to _not_ do with NetworkManager was to
maintain profiles.  Profiles as a concept aren't really user-friendly.
The best part about networks using DHCP (forget static IPs for a minute)
are that they "just work".  You don't have to know anything about your
own network configuration to get onto the network and to have a
connection.  You aren't required to pick a profile on startup, or to
specify a network profile on the kernel command-line.  This stuff is
just stuff that 90% of users (in a Windows, Mac, OR Linux world) don't
care a whit about, and I certainly don't want to have to do this when I
start up.  Its my humble opinion that if I can do anything possible to
not implement profiles in NetworkManager, then I'll do that thing.

Static IP is a different story, we have a few choices:  (1) screw static
IP, which I don't think is the best idea, (2) have some sort of profiles
for static IP users, (3) allow some sort of direct configuration tool to
be launched from the applet menu.  I'm not sure which is best, and I and
others are still mulling over what type of interface would be best for
the users.

Remember, the goal of NetworkManager is "Zero User Interaction", or,
really "It Just Works".  I haven't yet seen a well implemented profile
manager, from a user perspective.  I'm just not convinced they are the
best way to do networking things, a view which is in my opinion held up
by the vast majority of vendor wireless drivers and utilities in the
Windows world.  Cisco ACU, Orinoco, Netgear, etc, all have some sort of
profiles in their wireless drivers, and frankly they suck.  XP's
Wireless Zero Config is getting there, but still not there.  I'm
definitely trying to shoot higher than WZC, or even Apple's Airport,
here.
 
> very detailed information. NM does something similar with the gconf 
> database. Using gconf-editor, you can add, edit, and remove keys in 
> gconf but you cannot add a network using the gconf-editor. I suppose you 
> could edit the XML file directly. I created a network entry for my 
> campus where the essid's are hidden. I added to the addresses list the 
> MAC's of all the AP's I normally see. If my campus ESSID and WEP key 
> should change, I can easily edit these two keys.

Well, the other alternative is "gconftool2 -s --type
string /system/networking/wireless/networks/<essid here>", that will
also do the trick.  Its perfectly possible to write a small utility that
would front-end this; that's something I don't have time to do but would
be a great little project for somebody.  That's probably a day to hack
it up in Python, and then we can refine that tool over time or just keep
it as a functional proof of concept.  I would encourage somebody to
write this tool, and we could then talk about adding it to CVS.

> Does NM need its own internal database? Personally I do not have the 

I don't think so, not at this time.  GConf should work for the moment,
Colin Walters and I are looking at storing more information there such
as VPN settings.  The other thing about GConf is that
administrators/corporate types can lock the GConf settings down and
disallow users from accessing certain keys.  Specifically, they could
lock down VPN settings so that you cannot change your VPN server, which
might be desirable from a system administration standpoint.  I think
that the advantages of not doing this all by ourselves are more numerous
that, say, using a built-in DHCP client that doesn't do anything with
user-side policy (which we'd have to care about if we did our own
database).

> need to deal with static ip's anymore but for those that do, I can see 
> that it would be advantageous to be able to go into the NM database and 
> enter profiles that contained static ip's, dns, default printer, ... . 
> If NM is going to have its own dhcp client, does it make sense to use 
> the network profiles provided by the distribution. I think not. Like 
> IAC, the NM applet should present a dropdown menu of all defined 
> profiles and an option for starting the database editor, gconf-editor or 

The current static IP approach is to use the distribution's profiles for
IP, DNS, and gateway information.  Unfortunately, that doesn't work for
DNS right now, so our static IP solution is kind of a non-starter.  But
remember, the goal here is to make sure that the user has to do as
little as possible.  One proposed solution was to specify particular MAC
addresses that are known to be on a network, and then select a profile
based on that.  I think its quite reasonable to have the fail-over case
require the user to choose his/her network, but that should not be the
_first_ case.

> whatever. IAC allows the user to turn on autoswitching and specify what 
> to do when the current network is no longer available. IAC connnects 
> with equal ease to my home network where the ESSID is broadcast and to 
> my campus network where the ESSID's are hidden. This is something that 
> NM currently does not do. Everytime I boot on campus, I have to select 
> 'Other Wireless Network' and re-enter the ESSID and WEP key.

NM _should_ do this automatically right now, at least with CVS.  If it
doesn't then its a bug if you're always turning the laptop on in the
same location.  If you see the MAC addresses of the access points in
GConf, then NM should automatically connect to those access points when
its started up in range of one of them.  If you're new to the area (ie,
you've added your office but not the student union's APs) then adding
that access point through "Other Network" should work from then on.  If
you know the list of access points that are on campus, you could add
each of those (or, remember, an administrator could do this for you) to
your GConf and you should have no problem.  Eventually, after you've
chosen "Other wireless network" a few times, you should have majority
coverage of your campus and no longer have to do that.

The problem with non-broadcasting base stations is that there's _no_ way
to know, other than MAC address, what the ESSID of that station is, and
you cannot even attempt to associate with it until you know.  I assume
that in IAC you have to enter MAC addresses or something?  If not,
that's news to me, quite interesting, and worth much investigation.

The reason that we're not keying off ESSID is this.  Nobody says that my
neighbor couldn't use the same ESSID as is used at my work, and if NM
was keying off ESSID, then at home I'd connect to my neighbors network
rather than my own.  ESSID is _not_ the unique value here, the MAC
address is.  Its also a security concern in this case, something we try
to think a lot about when working on NetworkManager.

Also, if your wireless card supports roaming, the card will hop from AP
to AP automatically without user intervention.  I think most cards these
days do this, but at least with the Orinoco/Lucent cards there's a
special option for it.  After NM connects to an AP using the MAC
address, if present, it doesn't care what MAC address the card is
connected to as long as the ESSID stays the same.  Therefore, you should
be able to roam around campus without problems, even if the laptop
doesn't automatically connect when started up.  WRT the paragraph above
& security & uniqeness of ESSIDs, if there's an untrusted access point
within range of your campus access points that's using the same ESSID,
then we've got more problems than NetworkManager cares to deal with.

Hope this helps somewhat, and thanks for your ideas & explanations.
Lets try to get NM working as well as possible for the users.

Thanks!
Dan