Networking

Differences between revisions 2 and 3
Revision 2 as of 2007-11-21 21:31:16
Size: 5950
Editor: bismuth
Comment: Added note re: NM 0.7 and also modified 'Packages affected'...
Revision 3 as of 2008-01-28 17:33:13
Size: 6319
Editor: 192
Comment:
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
In order to provide an ''easy to use'', ''always connected'' mobile consumer device experience, improvements need to be made to both the user interface, and the core behavior(s) of Network Manager and it's associated applications. 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.
Line 10: Line 10:
''Note'' - some improvements may fall out of the the switch to Network Manager v0.7 in Hardy, however those changes alone may not suffice. The changes proposed fall into a few categories:

 * Simplify the UI for the average consumer
 * Add missing features
 * Next-gen networking support
 * Make it ''just work''!
  • 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.

The changes proposed fall into a few categories:

  • Simplify the UI for the average consumer
  • Add missing features
  • Next-gen networking support
  • Make it just work!

Release Note

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

That said, if any of the improvements described in this specification were to be included as part of Desktop, end-user impact is expected to be minimal; at a minimum, requiring the end-user to learn the simplified user interface and it's beavior(s).

Rationale

Network Manager ( from here on, Network Manager refers to both the network-manager daemon process, and the UI provided by the network-manager-applet, and gome-system-tools packages ) currently provides a user interface which both too "techie", and in some measures incomplete with respect to the mobile devices. For instance, how many people understand the difference between WEP 64/128-bit Hex and WEP 64/128-bit ASCII? Why should a user be forced to pick the type of security for passphrase/key? To further exemplify, the default Type on the passphrase dialog for a WEP access point is: WEP 128-bit passphrase, which if selected instead of WEP 64/128-bit ASCII won't associate with the desired AP. Examples of missing functions include:

  • no UI for enabling/disabling network radios ( eg. Bluetooth, Wi-Fi )
  • no UI for enabling/disabling power management

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

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