Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

Summary

Provide a better user experience when connecting/disconnecting to/from various dynamically configured networks. Must gracefully handle falling back to static configurations.

Rationale

For mobile users of Ubuntu, there is no easy default way to handle network roaming. While network-admin can allow for the configuration of both static and DHCP-controlled interfaces, wireless network selection is needed. While network-manager can be used for DHCP-controlled interfaces and wireless network selection, static network management is needed.

Use cases

  1. Brian travels between home, work, and conferences with his laptop. Each location has a wireless network available, but the available ESSIDs may not be known ahead of time. He wants a simple drop-down list of available wireless networks that he can connect to.
  2. Bryce takes his laptop with him on customer visits where he uses DHCP for his wired connections. However, when returning to the office, he needs to switch back to a static wired network assignment.
  3. Bart wants to be able to manually enable and disable his manually configured interfaces from network-manager.
  4. Bilbo wants to be able to send out email from his postfix queues whenever a network becomes available with network-manager (ifup.d scripts need to be run by network-manager).

Scope

The intention is to make the least possible number of changes to network-manager and network-admin, in an attempt to satisfying this spec, with the expectation that post-feisty versions of network-manager will have solved the lack of static address management.

Design

Currently in Ubuntu, network-manager totally ignores interfaces that have been modified in /etc/network/interfaces, and getting it to notice them again requires manually editing /etc/network/interfaces.

To fix this temporarily (until Network Manager can do static configuration itself), we will let people specify automatic configuration per interface in network-admin. In more detail:

This is a stop-gap measure until upstream network-manager handles location-based static configurations. Pete Goodall will be communicating with Robert Love directly.

Implementation

Gnome Code

KDE Code

knetworkconf already uses text labels where Gnome's network-admin uses three-way tickboxes so this does not need to be changed.

Backend Code

Areas of future discussion

Possible future spec proposal

Instead of kludging back and forth between network-manager and network-admin, plus having a solution which relies on a working X11 session for networking to function (if you are in the wrong mode this could even effect wired access), how about the following:

Comments

The wpasupplicant package brings basic roaming support, and is already in edgy. The wpa-roam support is limited to one interface, due to contraints of the ifupdown package.

Why using wpasupplicant as base for roaming? - It does already background scanning and selects the 'best' (as configured and prioritized) available network. It can be controlled from any client using a socket. For configuring new networks, the control interface can be used to add new neworks. The latest development version (which is in edgy as well) also introduces dbus bindings. Btw, NetworkManager relies on wpasupplicant as well for roaming AFAIUI.

For this spec, I'd suggest that a roaming policy daemon is designed, which integrates into wpasupplicant as 'action script'. wpasupplicant calls this action script each time a network is disconnected or connected. See wpa_cli(8) - parameter -a.

The alternate solution will also prevent a regression in advanced functionality, in order to use a simple / pretty interface (AFAIUI, network-manager does not play well with others: resolvconf, guessnet, pre-up, post-up, etc.).

Finally do we want this use case: 4. Bill has a middling ability with Linux/Unix and has his laptop out on the road and something (himself or an update ;-), kill X and he wants to google for help but finds he can't connect to hot spots and has to ask someone on another OS.

Or this one: 4. Bill looses X, but thankfully his laptop connects to an open hotspot auto-magically, he finds a solution on google and is back in X 10 minutes later.

I don't have a WPA network to test with at the moment, but my understanding is that network-manager already handles WPA networks.

It will (or it did last time I tried it), but it does not work with the normal ifup and ifdown commands or with any configuration options in /etc/network/interfaces. The summary above does not integrate network-manager with the Debian management and configuration it just allows another case where network-manager can take over the interface (DHCP or completely unconfigured).

This spec is specifically about creating the smallest possible change to n-m and n-a to make them work together in a reasonable way for feisty. The long-term goal (not covered by this Spec) is to have a fully integrated, well-behaved solution, which is where the "alternate" spec would find a home.

I don't know if this applies, but network roaming with current network manager in ubuntu asks for keyring password everytime it needs to access. This could be easily avoided by using pam_keyring. Right know it's a mayor PITA, could this be addressed here aswell? See more information on here: http://ubuntuforums.org/showthread.php?t=187874&page=3 I've seen many users asking for this.

Re: Comment on gnome-keyring password prompt - Sounds like you want desktop-wide single sign-on (SSO). That is a much larger spec, not specific to this spec.

The thoughts made as "Possible future spec proposal" seem to be very much the same I did on my notebooks. Also combined with guessnet one gets a very flexible basis for almost anything one could possibly think of. I wrote an Howto for it which may serve as a basis for such a spec. Since my lack of spare time at the moment it is only available in German.

Some day it would be nice if applications would get notifications about changes in network connectivity. Atm for instance Ekiga can't automatically figure that it has to work around NAT and GAIM doesn't know to reconnect to IRC etc... They are small things but cause inconvenience. How about sending some day D-BUS notifications?

Re: notifications about changes in network connectivity - This is already implemented in NetworkManager, but the individual apps need to utilize the dbus notification. Gaim, Evolution and Mozilla Firefox already do this in other distributions, so the code is there. IMO, this should be part of the work for Feisty in integrating NM.

We should also consider the following use case:

Bob uses his computer at home, at the office, at meetings, at friends' house, ... Sometimes he has to use static wired network configuration, sometimes he uses dhcp over wired networks and sometimes he uses dhcp over wireless networks.

Alice, Bob's girlfriend, also uses Bob's computer, mostly (but not only) at home. Alice doesn't have any administrator privileges and doesn't have any particular technical skill.

The system should work as follow: 1- if there is any active working connection, it must be aware of it, check if it already knows this network configuration and, if it doesn't know this network configuration, it must ask to the user if he or she wants to save current network configuration. 2 - if there is not any active working connection, the system must try among the previously saved network configuration if there is any working configuration and, in that case, it must ask the user if he or she wants to use one of the working configuration. 3 - if there is not any active working connection and the system can't find any working configuration among the previously saved one, the system should search for any working connection (searching among the wireless connections present, trying to discover any dchp server, ...) and if it finds any working connection, it asks the user if he or she wants to use it and add it to the known configurations.

The system must always give the user the possibility to define a new configuration (even if there is an already one active and working).

The system should work in the same way not depending on who is using it (Alice or Bob). Maybe that if Bob (the administrator) defines a new configuration may decide to share the configuration with the other users while Alice (the normal user) may only define her own personal configurations.

The system should be as clean as possible (if possible reuse existing tools like ifup/down, gnome's network applets, ...).

Just a little thing. One annoying aspect of having multiple network profiles is that the firewall (configured through firestarter) doesn't have any clue of profile switch. I have two profiles (one wireles with wired private lan, one wired) and, on change, I have to manually stop the firewall reassign public and private interface, and restart it. This is not always clear to non-expert user.

Sounds like changing networks should trigger a dbus event, and firestarter needs to be dbus-enabled to react to that event. Unfortunately, if it has not yet been implemented it probably is too late for the featue freeze.

Roaming is nice but I will be glad when I can use NetworkManager to set a static IP.

Now it's OK, but a nice feature would be the possibility of renaming the interfaces, because now, you can get a huge menu, occupying a large part of the screen, like in the following screenshot (resolution = 1024x768, screenshot scaled to 800x600): http://img232.imageshack.us/my.php?image=networkmanageras3.jpg

I have a question here. Since you've mentioned that you are going to leverage the current framework of ifupdown, how is security/firewall going to be tackled. ifupdown allows individual configuration of each network alias. I can have a configuration for my wireless device that when I've at home don't block anything, when at office block everything thing but allow certain ports and when I'm outside, block everything with a very high firewall rule. AFAIk NetworkManager doesn't allow this to happen. Is this feature going to be addressed ?

Another scenario that ought to "just work". User logs in using GNOME and password protected WiFi networking is automatically configured/connected. User then logs out... expecting network to stay connected... user then switches to KDE and logs in... expecting network to stay connected -- but currently that is not what happens. Instead the network connection is closed and KDE complains that it does not know how to connect to the WiFi network and that it does not know what the password is.... Ubuntu Hardy. codeslinger compsalot.com


CategorySpec

NetworkRoaming (last edited 2010-02-19 07:04:04 by 174-21-210-157)