(This is a informational document based on UDS discussions in Barcelona 2009)

What is Connection Manager

Connman is essentially created for moblin, but will also eventually be available for desktop installs; key characteristics are:

• low memory footprint
• quick startup
• light weight UI; all logic and all persistence (connection settings) is on the daemon side
• extensibility through plugin approach

Quick Summary

In general, connman is still in development stage and lacks features currently available for the standard NetworkManager. Hence, its not considered to be ready to replace NetworkManager as the default connection management solution for ubuntu karmic.

However, connman is available in the archive and is considered useful for special purpose downstream distributions (mobile, etc.).

Details

Abstraction for wireless support is also done through wpasupplicant.

New ideas in connman

New ideas that will eventually make it into connman are:

• connman (will) provide(s) a dns proxy that allows parallel dns requests; plan is to enforce that localhost is always set in /etc/resolv.conf; another option evaluated, but dismissed was to implement a libc resolver; main problems was too much overhead (implementation wise) as well as problems with dns result persistency/caching over reboots.
• connman will provide its own HTTP proxy mechanism
• new mechanism to define device priorities through drag-and-drop and magic (more info, see slides referenced in the documents section)

Current Status in Ubuntu

Current Status of connection manager in ubuntu

• recent connmand available in the archive
• connman-gnome in archive, but didn't get much upstream attention; finally things
  • started to move again
• carrick - connman UI for mutter (moblin2 ui framework) available in moblin PPA; soon to be in real archive.

Connman vs. NetworkManager (feature perspective

• See: https://wiki.ubuntu.com/DesktopTeam/ConnectionManagerComparison

Raw notes from the session

• ethernet, wifi, pppoe (dsl), VPNs, mobile-broadband
  • vpn not a priority for connman
  • no wpa-enterprise support yet; not a priority
• wifi
  • connman - keys, passphrases stored in clear...shared system wide
• mobile-broadband detection through udev - soon: modemmanager
  • Connman will use modemmanager, but currently there is a problem
    • with ppp; hso cards and ericcsson might work. ofono will eventually replace modemmgr
• multiple devices, but you cannot disable individual devices
  • connman managed multiple devices
  • enable all by default, but allows to disconnect it
  • advanced configuration mechanism to express preferences for
    • devices/ssids, etc.
• no "disconnect" feature for ethernet and wifi
  • connman you can disconnect ethernet devices
• killswitch support ( via Hal )
• support for older and/or proprietary full MAC wifi drivers ( eg. madwifi, wl )
• static IP configuration possible
  • not clear, but supported through command line and remembered might get a UI
• system connections (keyfile, ifupdown)
  • connmn - all configuration data ( including profiles right now ) are system-wide,
    • and user data from dbus is not stored...
• background scanning for roaming (considered harmful)
• connection editor
  • connman - currently no UI for this
• user feedback ( or lack thereof )
• user control ( eg. 'disconnect', 'scan' buttons, disable individual devices)
• connman dbus API - still not fully stable, may need a few more iterations...
• connman API has an offline mode ( ie. airplane mode )
• it also provides an offline/online status via the API
• connman manages all devices, will monitor them, but it also has the concept
  • of ignoring a device
• is the connection expensive ( eg. 3G vs. wi-fi ); it's do-able...

Outlook/Challenges

Online/Offline dbus API

• we need a std dbus API for online/offline; all connection mgrs ( wvdial, connman,
  • network-mgr ) should implement it.

  • implementations need to publish & listen ( ie. proxy ) at the same time

    • -- cooperative status monitoring --
• is there plans for counting bandwidth? No. It'd be nice to have...
• connman tells the UI what it needs ( eg. username/pw, certificate, passphrase,
  • etc... ); the UI is simple...
• what about discoverability for GSM? GSM scanning is expensive.
  • ofono - makes the decisions using simple alogorithm ( eg. us the SIM
  • card's preferred network ).

  How do we get testing data? Easy switching between NM & Connman?

We should standardize on an FD.o interface to signal:

• offline / online status
• expensive connection or not (relies on a series of 3 D-Bus calls atm, so might want to improve/evolve that)
• the instance that manages the bus namespace also has to accept information and consolidate

Documents/References

• connman intel presentation http://moblin.org/sites/all/files/lfcs2009-connman.pdf

• NetworkManager maintainer on connman vs. network manager: http://blogs.gnome.org/dcbw/2009/06/25/networkmanager-and-connman/

• Arstechnica comparison: http://arstechnica.com/open-source/news/2009/06/intels-linux-connman-examining-the-pros-and-conns.ars