NetworkRoaming

Revision 30 as of 2006-11-18 13:22:31

Clear message

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.

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

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:

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

Implementation

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

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.

  • -- 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 [http://www.hekanetworks.com/index.php/publisher/articleview/frmArticleID/25/staticId/31/ 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.

  • -- 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


CategorySpec