Re: couple of questions about the NM TODO
On 1/4/07, Dan Williams <[EMAIL PROTECTED]> wrote: On Thu, 2007-01-04 at 11:36 -0500, Bryan Clark wrote: > 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 travel a lot and typically connect to airport WAN's and/or customer site WAN's; however, these are typically one-time only or temporary connections that I plan on using only for a few hours. It would be great if NM had the ability to remove these old connections since I don't typically use those WAN's again and if I did I would rather re-establish the connection when I got there. Maybe have a way to mark a connection as temporary (i.e. don't remember beyond this session or timeout after X hours) or a way to remove stale sessions via the GUI-app? Thanks, John ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
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 interroga
Re: couple of questions about the NM TODO
On 1/4/07, Dan Williams <[EMAIL PROTECTED]> wrote: > > 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? How about trying in order of longest total connection time? Then your home or regular work connection is sure to get checked first. It seems that actually removing a connection is a function of the UI, not NM itself, and I thought knetworkmanager was capable of that (since I only use 2 networks, I could easily be wrong). -- derek ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: couple of questions about the NM TODO
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
