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 _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
