| |||||||||||||
|
| |||||||||||||
Making NetworkManager work with suspend/resumeMaking NetworkManager work with suspend/resumePosted Feb 27, 2009 16:52 UTC (Fri) by drag (subscriber, #31333)In reply to: Making NetworkManager work with suspend/resume by clugstj Parent article: Making NetworkManager work with suspend/resume
Network Manager depends on the driver to tell it what networks were in range and their relative strengths. It can't determine it on itself, it needs to be told what networks are available and using the network card to scan for networks is the only way to do it.
The problem with that is if you suspend your laptop, move it to another area and time, and then wake it up the Linux kernel will tell you that networks exist that are not really there any more. The driver has no notion of time when it's put to sleep and thus it tells userspace bad information.
So Bad Information in = Bad results out.
So in order to make Network Manager perform it's function correctly (which is track networks, connect to networks, manage passwords, run appropriate if-up/if-down scripts, manage VPN, etc etc in a mobile environment with continuously changing topography without user intervention if possible) then it needs to have reliable information from the kernel.
This blog entry is just a overview of the developer figuring out that it wasn't Network-Manager's fault for behaving badly when it was simply reacting appropriately to a flaw in driver design. Which he then fixed.
(Log in to post comments)
Making NetworkManager work with suspend/resume Posted Feb 27, 2009 19:25 UTC (Fri) by jengelh (subscriber, #33263) [Link] Simple as it seems, there are post-suspend shell scripts that can get run, and which could be used to kick NM to issue a rescan. # opensuse grep RESTART_SERVICES /etc/sysconfig/powersave/sleep
Making NetworkManager work with suspend/resume Posted Feb 27, 2009 21:53 UTC (Fri) by drag (subscriber, #31333) [Link]
Well ya....
But that is not what the blog post was about. Instead of mucking around with shell scripts to make NM work and being lazy, he was much more proud of actually fixing the buggy behavior in the drivers.
Making NetworkManager work with suspend/resume Posted Feb 27, 2009 20:01 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
since mobile IP has not been solved, it's not possible to transparently move from one network to another.
some things can recover from doing so, but many things cannot.
Making NetworkManager work with suspend/resume Posted Feb 27, 2009 23:07 UTC (Fri) by zlynx (subscriber, #2285) [Link]
Actually it pretty much has been solved. It's just inefficient and inconvenient.
Use your home system as the target for OpenVPN and use only your OpenVPN network for connections. It will keep the same addresses and reconnect your OpenVPN sessions transparently.
If you shift networks before your TCP sessions time out, they will still be running when your laptop comes up on the new network.
Making NetworkManager work with suspend/resume Posted Feb 27, 2009 23:51 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
... and TCP connections don't actually timeout unless they've got outstanding data. So its possible for a connection to live indefinitely in your absence if its idle. A SSH session with no "keep-alive" flag can survive you moving to a new house, setting up DSL and IP at the new house, and then reconnecting the intervening architecture. Tap enter a couple of times and it all wakes back up and continues...
But anyway, Mobile IP exists, I've taken part in live demos of it over continental distances, moving a device from a local network to a wireless relay and seeing a streaming video briefly stumble and then continue. But it /is/ a little bit inefficient, and more importantly it relies on you not having a network made of string and parcel tape (NATs and private IP) and thus it's not an option in the real world where expediency has long ago triumphed over good engineering.
Making NetworkManager work with suspend/resume Posted Mar 16, 2009 14:02 UTC (Mon) by robbe (subscriber, #16131) [Link]
> So its possible for a connection to live indefinitely in your absence
> if its idle.
In the 80's Internet, yeah. Today most interesting connections pass a
Making NetworkManager work with suspend/resume Posted Mar 30, 2009 16:29 UTC (Mon) by Lennie (subscriber, #49641) [Link]
Which would be a really good reason to start using IPv6. ;-)
Making NetworkManager work with suspend/resume Posted Mar 1, 2009 14:35 UTC (Sun) by renox (subscriber, #23785) [Link]
[[since mobile IP has not been solved, it's not possible to transparently move from one network to another.]]
I think that there were some 'loss of context' for this sentence, given that many phone users use mobile IP to transfer data..
Making NetworkManager work with suspend/resume Posted Mar 1, 2009 15:45 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
by mobile IP I am not referring to the problem of moving from one wireless link to another within one network (either a cell network moving between towers, or a wifi network moving between access points), that's an easy thing to do.
I'm referring to the concept that your machine (phone or laptop) can get one IP address and have that address work as it shifts from one network to another. In a 'working' mobile IP environment, you could move from wired to wifi to cell (including bouncing between different providers) and have your connections remain.
the example above of using a VPN to a home network are close, but not quite the same.
Making NetworkManager work with suspend/resume Posted Mar 2, 2009 11:59 UTC (Mon) by whitemice (guest, #3748) [Link]
> since mobile IP has not been solved
What?? Linux Journal as even had an article about the solutions - and it works great! IPv6 contains a solid solution for mobile IP among numerous other issues (like router performance, fragmentation, link-local addressing, etc...) Once you've been on an IPv6 network with WAN Bonjour/Zeroconf configured.... everything else looks so bronze age.
Making NetworkManager work with suspend/resume Posted Mar 3, 2009 2:21 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
the folks at OLPC would be interested to learn that 'it works great', it is something that they would love to do with their deployments, but the experts in the field say that it's not yet usable in the real world.
it sounds good in theory, but in practice it requires so much cooperation between everything that it doesn't work. I believe (but could be mistaken) that it also requires an IPv6-only Internet, which doesn't exist
|
|
||||||||||||