GNOME.org
 

Re: couple of questions about the NM TODO

Dan Williams wrote:

On Thu, 2007-01-04 at 11:36 -0500, Bryan Clark wrote:

"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.

Sounds like a really good solution to me.

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.
Not really my concern here, just to nit pick you, if a newly run app (in the case above) uses the wired connection and then the cable is removed doesn't that app require a network disconnect signal? I can see that the app will continue to have a valid route, but it's TCP connections will still be terminated, right? 
"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 :)
Yeah, I think the way that works is completely reasonable. Often there are more than one of those default access points available so having the person choose the right one is the best we can do.
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?
Exactly, I keep connecting back to the 1369 network which costs $8 a day but I'd rather stay on the free city hall network which gets bounced every now and then. I feel like there's something we could be doing at the point you reconnect to a wireless network where we can offer options for removal of a certain network or access to an admin window. Not sure about that, but it seems the point of decision for the user is when NM goes to connect back to a network that I don't want it to, therefore might be the best point to offer the remove/admin action.
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.
Sure that sounds pretty reasonable, the policy kit seems like it's going to affect a number of applications in a similar way so we should probably keep in mind doing something that works well for them as well as NM. 
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.
Oh good times! 
~ Bryan
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]