Ubuntu Wiki

• Launchpad Entry: coming soon...

• Packages affected: network-manager, network-manager-applet, gnome-system-tools

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

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:

• Suspend / Resume -- consumers cannot be expect to have to re-start NetworkManager after a device wakes from sleep;

• Better User Feedback -- if something fails, there needs to be better feedback to the user ( eg. association to the AP failed, couldn't get an IP address )
• Gnome Keyring -- should it be a requirement for MIDs?

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. Peter attempts to connect to an AP with his mobile device. He types a key which although valid ( ie. it's the correct length ), is wrong. When his mobile devices fails to get an IP address, the passphrase dialog is automatically redisplayed with an error message asking him to check his key.

4. Jason buys a new access point and connects to it with his mobile device. A co-worker tells him he'd better enable security on the access point. He does so, and now when he tries to connect to the AP, it fails to associate, and then re-prompts him for a new passphrase and/or key.

Note - ideally there'd be some way to change or clear the current key associated with an access point so that you don't have to try and fail before entering a new key.

5. 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 puts her device to sleep, when it resumes from sleep at some later time, she should not have to use "Join Other Network" in order to re-connect to her access point.

Note - this could be a bug in NetworkManager, user error, or it's the way it's supposed to behave. If it's the latter, it should be changed...

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

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

Design

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

• data migration, if any
• redirects from old URLs to new ones, if any
• how users will be pointed to the new way of doing things, if necessary.

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

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

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