Re: couple of questions about the NM TODO

[Dan Williams <dcbw redhat com>]

On Thu, 2007-01-04 at 11:36 -0500, Bryan Clark wrote:
> Hey all ~
> 
> Saw the TODO linked from Dan's post and wanted to comment on some of the 
> items, it's probably obvious which one I'm going to start with. 
> 
> "Warn users of (in)unsecure wireless networks...".
> 
> I just wanted to say I think the idea is valiant, however the method is 
> not going to achieve the idea.  The people who care about security will 
> have already setup a secure network to use and the people who don't care 
> about security aren't going to change their behavior because of a dialog 
> we put up, it'll just be annoying noise to both crowds.  There's lot of 
> evidence out there that these kinds of methods aren't effective, 
> application developers have to decide best practices and make those 
> defaults or it doesn't really matter.

Yay for wikis.  I don't know who added that, but they didn't talk to me
(or I don't remember them talking to me).  Reverted.  Furthermore, NM
will never connect to any network you haven't connected to explicitly.
Furthermore, some networks like Dynamic WEP and some 802.1x don't look
encrypted (I think) but actually are quite secure.  So this warning
doesn't really serve a purpose.

> Near to this, I've seen mail traffic in the past with concerns about NM 
> auto switching perhaps while you're away from the computer [1].  I think 
> this is a different problem that can be handled differently but wanted 
> to address it a little.  If your system is idle when network manager 
> auto switches networks perhaps the notification bubble should stick 
> around until it's not idle and then behave as it normally does.  That 
> might be a behavior that needs to be looked into for other notification 
> bubbles though.

Yeah, this sounds like a good idea.  I wonder if the notification
library has the infrastructure to support this.

> "Multiple Active Devices"
> 
> I just wanted some clarifications about how this is going to effect our 
> average laptop user.  Lets say one of the situations we originally 
> designed for, which was having your laptop on wireless and then plugging 
> into a wired connection.  I'm assuming that both wireless and wired will 
> be active at this point and it seems that you plan (in this situation) 
> to add the wired device as the default, higher priority, route.  Is the 
> wireless going to continue to be active?  Is the user going to continue 
> to receive notifications about changes in the secondary devices?  Just 
> thinking that if my wireless connection is bad and I plug into a wired 
> connection, am I going to continue seeing my wireless connection bounce 
> around even though I'm not (expecting that I'm) using it.  Just looking 
> for some clarifications to the behavior.

We've had problems here before.  People got mad when we automatically
switched no matter what, but that was because NM was cutting TCP
connections out from underneath apps.  Right now NM will stick with a
connection you've explicitly chosen from the menu until that connection
is no longer valid, no matter how much you plug/unplug a cable if you've
picked a wireless AP.  But that's confusing because many times you _do_
want to switch when you perform an explicit action like plugging in the
cable.

I think having multiple active devices will help this situation because
NM won't be deactivating a device just because another one activated.
So in the previous case, just plugging in the wired cable might change
the default route; but it won't terminate every TCP connection you
currently have open, which is the main gripe people have about the
current autoswitching behavior.

For multiple active devices, NM will switch the default route to point
through the "best" device, but would keep routes and such for other
devices until their link goes away.  Apps wouldn't get signals about NM
being "disconnected" unless _every_ network device was disconnected.

> "Don't connect here again"
> 
> I know NM keeps a laundry list of connections I've made like a personal 
> wireless little black book.  However we never spent much time on how to 
> stop NM from connecting to certain wireless networks.  Is something like 

One thing we're supposed to be doing here is _not_ autoconnecting to
manufacturer default SSIDs like 'linksys' or "Netgear".  I think that's
broken in current CVS though, but we shouldn't be doing that.  If people
find it annoying that NM won't connect automatically, then change the
damn SSID to something other than the manufacturer default :)

> this in the works?  For me this problem only really occurs in what I 
> call the "conference scenario".  Where you're at a conference and 
> looking for the wireless, possibly trying a few different connections 
> that don't work until you find one that does.  However next time you're 
> up and running NM continues to try all the other connections if it 
> doesn't see the last one that worked.  Since I haven't been to a 
> conference in a while this isn't much of an issue for me anymore, but 
> was something I wanted to think about fixing.

By this, you mean that you can successfully connect to a network (ie get
an IP address) but that you need to either pay $$$$ or log in or
something?  That case we don't handle so well right now.  Perhaps we
should "forget" save details of an unknown network that you were only
connected to for less than 3 minutes or something.  Ideas?

> I also have questions about the system wide policy stuff, but there's 
> probably a better list to interrogate the davidz on how he plans for 
> people to the set system wide policy options.

Yeah, and now's the time to start talking about that.  We're pretty much
going to have to have a config-type applet that allows you to put in
details for stuff like WPA Enterprise connections, because that stuff
just cannot be autodetected at all (since it's entirely orthogonal to
how the AP is configured and the 802.11 authentication/association
process).  We were thinking that this config applet would have a "Let
other people use this connection" button that pushes the settings to the
entire system.  But your thoughts here would be greatly appreciated.

I can also regale you with horrid pictures of the 802.1x configuration
dialogs that other OSs use so that I can get some thoughts from you on
how to clean that up.  But at a certain point I just think we have to
suck it up and let people enter the options (or the sysadmin puts them
in via GConf or something).  It's ugly.

Dan

> Cheers,
> ~ Bryan
> 
> [1] 
> http://mail.gnome.org/archives/networkmanager-list/2006-May/msg00064.html
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list