Summary

This blueprint proposes a set of functional changes to NetworkManager and its associated applications / infrastructure for the purpose of making networking just work on mobile devices. The focus is Ubuntu Mobile, and driven in part by a MID ( Mobile Internet Device ) customer's requirements, however many of the proposed changes also could be leveraged on the desktop. Also please note that this blueprint should not be considered a design document, however at times it may be necessary to dive deeper in order to illustrate why certain things don't work.

Release Note

As there has not yet been an official release of Ubuntu Mobile, end-user impact is not applicable.

Rationale

The changes proposed fall into a few categories:

Simplify The UI

The aim here is to re-work the NetworkManager related user interfaces such that non-technical users can easily operate them. The default UI should strive to reduce usage of technical terms like ASCII, BSSID, Hex, or WPA2 when at all possible.

Add Missing Features

Certain features are missing from the current version of Ubuntu Mobile and are expected to exist in a mobile consumer device. The primary example of a missing feature is the ability to turn off the Wi-Fi radio from the UI. Some devices also may have an actual hardware control to toggle Wi-Fi radio power which will also needs to be supported. Another example of a missing feature is the lack of an interface to change or delete a saved passphrase / key of a previously connected Wi-Fi access point.

Next-Gen Networking

Support for next-generation networking technologies like 3G and WiMax need to be added. Not much more to say...

Make it Just Work!

Some areas that need improvement:

It should be noted that some of the problems seen on Ubuntu Mobile today are due to architectural problems. One major problem is the fact that MIDs are designed to run as a single hard-coded user with no login nor password required. This coupled with the fact that MIDs run a hybrid of the Gnome and Hildon the desktops as opposed to a vanilla Gnome desktop causes a variety of problems related to Gnome applications such as gnome-keyring and network-admin ( part of gnome-system-tools package ).

One last note... NetworkManager 0.7 is currently in mid-development cycle. Some of the ideas presented in this blueprint have been mentioned in the outlined plans for the 0.7 release. Hopefully this blueprint will generate discussion with the NetworkManager developers and lead to co-operation on some the features described herein.

Use Cases

1. Ozzy tries to connect his new mobile device to his nephew's home access point, who scribbled a WEP key value on a piece of paper before leaving for vacation. Ozzy doesn't know the difference between a passphrase, an ASCII key or Hex key. He selects the access point, and is prompted for a Passphrase / Key; the dialog figures out the type and does validity checking without making Ozzy select the type.

2. Sheila boards an airplane with her new mobile device, to turn off all radios on her device, she clicks the Airplane Mode icon on the Network Settings page; all radios ( eg. Bluetooth, Wi-Fi, 3G ) are turned off and the icon changes to show that Airplane Mode is active. Upon landing, Sheila clicks the Airplane Mode icon, each radio is enabled, and if possible, the device re-connects to the Internet without manual intervention.

3. Zach decides to revoke his neighbor's usage of his access point due to his neighbor downloading too many torrents of old TV shows. He changes the passphrase of his access point and wants to update his mobile device to use the new key. He opens the Connection Manager and changes the passphrase.

4. Maria decides to change here access point so that it doesn't broadcast it's ESSID. She does so, and uses "Join Other Network", this connects her mobile device to the Internet. Maria then inadvertently lets the battery run out on her mobile device. When she plugs it and boots the device, it automatically connects to her home access point.

5. Phil is a providing support for mobile devices using Unbuntu Mobile; while reviewing the daemon.log file from a device, he no longer needs to wade through HAL events which aren't relevant to networking.

6. Alice uses a mobile device running an OEM-customized version of Ubuntu Mobile. In order to connect to a 3G network, she selects 3G from the nm-applet's menu. If she hasn't yet entered the credentials for the 3G provider, she's prompted to do so.

Assumptions

The remainder of this blueprint consists of application specific sections with the exception of the final two sections:

Gnome NetworkManager Applet

This section covers changes to the Gnome NetworkManager applet including:

Simplified Key / Passphrase Required Dialog

When a user selects a Wi-Fi network from the nm-applet menu, and the selected network requires a passphrase or encryption key, a dialog titled Wireless Network Key Required is displayed. This dialog displays a different set of widgets depending on the type of access point selected. Currently, there are three different versions of this dialog corresponding to the following Wi-Fi security schemes:

Each of the versions of this dialog require the user to select the type of key / passphrase entered from a combo-box labeled Wireless Security, and enter the corresponding key or passphrase. Each of the dialogs also have scheme-specific settings which can be changed via additional dialog widgets. All versions of the dialog include a checkbox labeled Show Password, a Cancel button, and a Login to Network button.

WEP

The WEP Wireless Security combo-box options are:

An additional combo box labeled Authentication is also present with the options:

WPA Personal

The WPA Personal Wireless Security combo-box options are:

An additional combo box labeled Type is also present with the options:

Note - I also believe it's not possible to use a full 256-bit WPA Personal key with the current implementation which I believe only supports WPA Personal passphrases only. I need to do some testing to verify...

WPA Enterprise

TBD

Simplified Dialog

The new simplified version of the dialog will remove the Wireless Security combo altogether for all three versions of the dialog. The justification for this is that most consumers really don't understand the meaning of terms like ASCII, Hex, WEP or WPA, let alone the difference between WPA and WPA2. Futhermore LEAP is a proprietary Cisco security scheme, and WEP 128-bit passphrase is an out-dated passphrase scheme which is rarely used these days. With the removal of LEAP and 128-bit passphrase from the WEP version, it's possible to determine the key type by examining the text entered into the key / passphrase dialog. One only needs to take a look at the equivalent dialogs in OS X or Windows XP.

The second change involves hiding the additional settings widgets ( Eg. WEP Authentication ) via an Advanced button which would toggle the visibility of the advanced widgets.

TBD - add screen capture of new dialog here

If there is strong opposition to removing the ability to use LEAP and WEP 128-bit passphrases from Ubuntu Mobile, then an option would be to include a Wireless Security over-ride combo box in the Advanced panel. This technique could also be used to support WPA / WPA2 - Enterprise security methods.

Terminology

One other minor point is that the term Wireless Network is too generic, especially when MIDs may included 3G or WiMax radios ( other examples of Wireless Networks ). Other terminology changes include:

Association Failed Behavior

The current behavior of nm-applet if manual association ( ie. the user clicks on the AP in the nm-applet's menu ) fails is to re-display the Key / Passphrase Required dialog with the previously entered key cleared. There's no text indicating what exactly failed ( eg. association failed, DHCP failed to get an IP address, etc... ), just the re-display of the dialog. Note - I haven't exhaustively tested all of the failure cases, so I could be wrong with respect to the fact that the Passphrase Required dialog is re-displayed in all cases.

Connect to Other Wireless Network...

Connect to Other Wireless Network... is an item found in the main menu which launches a dialog of the same name which allows a user to manually specify the settings of a network ( hereafter referred to as a manual network ) and connect to the network. It typically is used to connect to an access point that isn't broadcasting its ESSID, and therefore doesn't appear in the list of networks visible after a scan.

Dialog Changes

This dialog by default displays with a text field labeled Network Name and combo-box labeled Wireless Security ( default is None ). The combo-box options are a super-set of all the possible options for all three variations of the Wireless Network Key Required dialog.

Again in the spirit of simplification, the Wireless Security combo-box options should be reduced to the following:

TBD - whether or not these methods should be supported on MIDs.

Also, as with the Key Required dialog, optional settings are also displayed based on the security type chosen. As with that dialog, these optional settings should be hidden via an Advanced tab/button.

Finally, this dialog has a Cancel and Connect buttons. For consistency sake, Connect should be re-labeled Login to Network.

Behavior Change

If the user enters settings for a manual network and clicks Connect, the new network's settings are saved, and a connect attempt is made. If the device goes through a suspend / resume cyle, NetworkManager will attempt to re-connect to the manual network again. If the user then switches network connections, or the device is re-booted, the manual network is effectively orphaned. If the user again wishes to connect to this network, they're required to click Connect to Other Wireless Network... again and re-enter the network settings and login again. Note - confirm behavior if the user switches networks; I've confirmed the reboot behavior..

Here are proposals for new behavior:

Refresh Scan / Networks

One of the things that's very frustrating about the current implementation of NetworkManager is that user is not given any control over the Wi-Fi scanning process, nor is much feedback given to the user other than the list of networks being updated periodically.

Two suggestions are:

Note - at a minimum, it'd be nice to see these functions/events added to NM's dBUS API.

Simplified Connection Information

If the device is connected to a network, when the user right-clicks the nm-applet icon and then clicks the Connection Information menu item, a dialog titled Connection Information is displayed. This dialog is read-only and displays the following information:

This dialog should be simplified. Consumers don't care about drivers and/or device names. Also it'd be nice if the type of Wi-Fi was displayed ( eg. 802.11a vs. 802.11abg, etc... ).

Other Wireless Technologies

Currently nm-applet displays a menu item for Wired Ethernet ( if an Ethernet cable is plugged in with hot carrier ) and Wireless Ethernet. If a device has additional wireless capabilities ( eg. WiMax, 3G, etc... ) in addition to Wi-Fi, then dynamic menu items should be added for these connections. In addition, as with Wi-Fi, if credentials are needed to connect, then protocol-specific dialogs need to be added for gathering credentials.

In addition to the main menu and credential dialogs, the Connection Information dialog will need to support any additional wireless protocols.

Miscellaneous Changes

ConnectionManager

The current NetworkManager implementation on MIDs lacks several features which are sorely needed in a consumer device. Some of these missing features are:

ConnectionManager is a new application that allows a user to manage all of their networking settings from within a single application. In some ways it's a replacement for Gnome's Manual Configuration application ( network-admin ), but in fact, it's much, much more.

This first draft focuses on Wi-Fi and Ethernet. Subsequent revisions will address UI / features for 3G, WiMax and other next-gen networking capabilities.

Global Radio Control

A simple UI mechanism will be provided ( eg. a toolbar button ) to toggle power to all network radios ( ie. Airplane Mode ).

Per-Network Global Settings

ConnectionManager provides separate per-network global settings pages.

Wi-Fi

The following are two instances of Wi-Fi global settings. TBD - flesh this out...

Per-Network Connection Management

Wi-Fi

This facility enumerates all saved Wi-Fi networks. It clearly marks the currently associated network, and allows the user to:

UI Design

TBD

Just Make It Work!

TBD

Design

ConnectionManager

Changing Saved Key / Passphrases

One of the so-called missing features mentioned at the start of this blueprint was the ability to change the saved key / passphrase of a Wi-Fi access point. This was a bit of a white-lie as there are two methods of doing so. Both have problems that make them challenging for a non-technical user.

The first method is described earlier in the nm-applet section Association Failed Behavior. If NetworkManager detects that association fails for a certain subset of secure access point types, it will re-display the Passphrase Required dialog in ~20-30 seconds. This behavior is very useful, however:

The second method is to use the gnome-keyring-manager application. There are several problems with this method:

Wireless Radio Power Management

This sections discusses three components of wireless power management, mostly focusing on Wi-Fi, as some of the other wireless technologies ( eg. 3G ) being used are based on closed-source drivers.

Radio On / Off Support

This section discusses several of the technologies involved in supporting user-control of radio on / off support.

HAL KillSwitch Support

Version 0.5.10 of HAL supports a new interface ( via dBUS ) called KillSwitch which allows a userspace application to monitor the radio status of a device and/or toggle the power to the device. It should be noted that the current implementation doesn't provide dBus signalling; applications interested in power status of a device must poll the device's status using the KillSwitch:GetPower method. HAL uses shell scripts to monitor and/or toggle the radio via driver-specific command-line tools or via driver-specific ioctls via the iwpriv command-line tool. This technique allows new KillSwitch enabled devices to easily be added to the system. The current 7.10 ( Gusty ) release of Ubuntu supports two devices...

The current version of NetworkManager ( 0.7 ) has rudimentary support for polling a KillSwitch capable device every five seconds to detemine if the device has been powered off.

For MIDs, the UI for toggling wireless radio power should use the HAL KillSwitch support.

Power Policy Manager

Intel is promoting something called a Power Policy Manager on a site they sponsor called lesswatt.org. It consists of two components, a daemon process called ppmd, and a command-line program called ppm-tool.

The Power Policy Manager framework creates three abstractions for power management:

The current implementation of PPM uses HAL daemon to receive AC power on/off events. The current set of plugins are written in C, and use various methods to control the hardware including:

The PPM defines a dBUS interface, however this interface currently doesn't appear to support signals.

There seems to be quite a bit of overlap with functionality provided by HAL and Gnome Power Manager. Also, the current plugin implementation is far less flexible than that provided by HAL, or Upstart.

rfkill

The rfkill switch subsystem is a relatively new kernel feature ( added in 2.6.22 ) which allows provides handling of dedicated hardware buttons used to toggle the power of wireless radios. It was designed for Bluetooth and Wi-Fi, but could be extended to other types of wireless devices. rfkill consists of two kernel modules, rfkill ( CONFIG_RFKILL ) and rfkill-input ( CONFIG_RFKILL_INPUT ). The rfkill module provides the core functionality of toggling radios in response to events funneled from rfkill-input and/or userspace applications using the /sys interface provided by rfkill. Userspace applications may also monitor the operation of rfkill via the /sys interface.

It should be noted that rfkill requires driver participation in order to operate. Currently, there are one or two wireless drivers ( ipw2100, bcm43? ) that partially work, but at this point, the kernel rfkill facility can be considered a work in progress. It's included here, because it's incorrectly referenced in the NetworkManager ToDo document for 0.7, which in reality refers to HAL KillSwitch integration, not kernel rfkill integration.

ACPID

TBD

Wi-Fi PS-Mode

At a minimum, NetworkManager should provide some way

Dynamic Power Management

Gnome Keyring Manager

The current version of Ubuntu Mobile is a hybrid of the Gnome and Hildon Desktops. One of our MID customers complained about the fact that they are prompted to enter a password for the Keyring Manager the first time they connect to a secure Wi-Fi access point ( note this happens after they've entered the key / passphrase ), and are also prompted for the same password when the system is rebooted. This is due to the fact that the network-manager-applet is stores access point keys and/or passphrases using the user's Gnome Keyring, while the remainder of the attributes of an access point are stored via GConf.

Note - see Gnome bug #386866 for details of other people that complain about the use of the Keyring Daemon to store Wi-Fi key / passphrases:

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during CD testing, and to show off after release.

This need not be added or completed until the specification is nearing beta.

Outstanding Issues

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.


CategorySpec

MobileAndEmbedded/Networking (last edited 2008-08-06 16:35:06 by localhost)