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.


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

  • Add network-manager to default install.
  • Allow switching to static network assignments by adding hook to network-manager drop-down.
  • Allow switching to dynamic network assignments by adding hook to g-s-t's network-admin.
  • Allow activating/deactivating ifupdown interfaces in n-m, if code changes are minimal.


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


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.


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:

  • The misuse of checkboxes (especially indeterminate checkboxes) next to the interfaces should be removed. Instead, if an interface is not configured by network-admin, "This network interface is not configured" should instead read "Managed automatically" if the interface is controlled by Network Manager.

  • In the "Properties" window for an interface, the "Enable this connection" checkbox should be replaced by a "Configure connection:" option menu with three items: "Off", Automatically", and "Manually". The rest of the controls in the window (other than Cancel+OK) should be available only if the menu is set to "Manually".
  • Network Manager's menu should include a "Manual Configuration..." item, which launches network-admin.

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


Gnome Code

  • Add "Configure Network Manually" to left-click drop-down item in nm-applet, which launches network-admin.
  • Replace network-admin's abuse of indeterminate checkboxes with more obvious icons representing "disabled", "enabled", and "automatic configuration".
  • Add "Configure Automatically" button to network-admin to restore control to network-manager.
  • Verify string additions and UI design with mpt.

KDE Code

  • Add "Configure Network Manually" to left-click drop-down item in knetworkmanager, which launches knetworkconf.
  • Add "Configure Automatically" button to knetworkconf to restore control to knetworkmanager.
  • Verify string additions and UI design with Celeste.

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

Backend Code

  • Use ifupdown to choose/control manually configured interfaces from network-manager.
  • Call ifup.d scripts when interfaces become available from network-manager.
  • Add dependencies to ubuntu-desktop and kubuntu-desktop to enable network-manager by default.

Areas of future discussion

  • DNS clobbering can be a side-effect of work in this area. See the spec GetRidOfEtcResolvConf.

  • When using bad kernel network drivers, network-manager will remain unusable, but manual configuration will already exist, causing no change in behavior. To help solve driver problems going forward, it may be helpful to create a list of "known good" drivers/hardware. Areas of current driver brokenness:
    • functioning... at all
    • signal level reporting may not work
    • power saving
    • software kill switches...
    • suspend/resume bugs
  • The need for pre-login networking (e.g. network authentication) remains, but this is already a problem, so adding network-manager does not change the situation.
  • network-manager's WPA support may need more attention, but people already using wpa_supplicant directly will not be impacted, and those who are not will gain network-manager's WPA support.
  • There are concerns about the icon display policy, but these need to be addressed upstream and do not impact the immediate utility of network-manager:
    • Gnome says user should be able to select whether or not an icon is visible (for example, power-manager).
    • Having the icon visible by default is desirable for support, so that the user can quickly get to the "Connection Information" drop-down.
  • For people that are already familiar with network-manager, there may be an interest in various VPN plugins that are not available by default in Ubuntu. However, having network-manager available by default will already be an improvement for this use-case.

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:

  • wpasupplicant running as a daemon for each wireless interface (supported method of operation, no coding needed).
  • ifplugd managing connections / disconnections.
  • wpa_cli provides a very simple interface to wpasupplicant (lists available networks, connects to a network, saves the configuration).
  • The wpa_cli could be wrapped with a relatively small amount of effort, providing similar functionality to network-manager, plus being integrated with the normal network commands (I would be happy to write a python applet with some help or assist in writing this applet).
  • Continue to use the network-admin for locations (even better add a location swapper to the above wrapper).
  • Add resolvconf and a search field to the network-admin DNS configuration to allow search domains to work with DHCP (this is included with windows and OSX, and it's probably not just me that use it ;-).


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.

  • -- Reinhard Tartler

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.

  • -- David Personette (dperson)

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

  • -- David Personette

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

  • -- Pete Goodall

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.

  • -- Matthias Deege

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?

  • -- Erich

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.

  • -- Pete Goodall

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, ...).

  • -- Dave Vernizzi

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.

  • -- Gianpaolo Racca

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.

  • -- Pete Goodall

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

  • -- Eric Lake

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):

  • -- Filiprino How did you get a screenshot like that? I've been using NM since Dapper, and it has always shown "Wired Network" for those connections.

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 ?

  • -- Ritesh Raj Sarraf

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


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