For handling network management tasks, at least on the desktop, most
distributions (and thus Linux users) rely on NetworkManager. But, there is
an alternative, called ConnMan, that was
originally created as part of Intel's Moblin effort. ConnMan has found its way into
Moblin's successor, MeeGo, which is no surprise, but it is also suited to
smaller embedded Linux systems as well. ConnMan's creator,
Marcel Holtmann, gave a talk at LinuxCon to describe ConnMan, along with
some of the challenges faced in creating a compact network management tool
that is targeted at mobile devices.
Holtmann started out by describing the "wishlist" for mobile devices that
he came up with when he started working on ConnMan three years ago.
Mobile phones were the first use-case he considered because they are
complex devices with limited battery life. Also, "if you solve the
phone case, you solve the tablet and netbook problem as well", he
said. In addition, the needs of televisions are a subset of those needed
for mobile phones.
But, other use-cases are different. Cars have different requirements, as
do robots, sensors, and medical devices. The only use-case that was left
out was the data center because it is "simple and pretty much
static", he said.
So, after considering those use-cases, Holtmann came up with a wishlist
that consisted of a handful of
high-level constraints. It should be a simple and small solution,
"but at the same time, really powerful". It should be
automated so that it didn't have to ask the user what to do "over and
over again if we knew what to do". It should have minimal
dependencies so that it could run on memory-constrained devices. It should
also support customization so that vendors could create their own UI on top
of the core. ConnMan sprang out of that wishlist.
There were also a common set of problems that a network management
application needs to deal with including IP address assignment, which is
"quite complicated actually", especially when considering
IPv6, he said. Dealing with network proxy support is another problem area
because the "settings are really hard to explain", so there is
a need to handle it automatically. DNS handling can be problematic as well.
There are interaction problems too. "Are we on the internet?"
is a surprisingly hard question to answer as the system could be connected
to a hotspot that requires a login for example. There is a need to make
applications aware of internet connectivity—gain or loss—as
well. In addition, time synchronization is important, but even more
important sometimes is determining the correct timezone. All of this stuff
needs to be sorted out before telling applications that the internet is
available, Holtmann said.
Beyond that, there are some additional features required for mobile devices
today, including a flight (airplane) mode, tethering, and statistics
gathering. The latter is particularly important for devices where
different kinds of connections have different costs.
Holtmann said that he looked at how other network management applications
are designed and saw a fundamental problem. Instead of keeping the policy
and configuration in the low-level connection manager, those parts live in the UI,
he said. He thinks this is the "wrong approach" and that
policy and configuration should live in the connection manager so that
experts can deal with the hard problems, rather than making users figure
them out. In addition, it allows UI developers to change the interface
easily, because they don't have to change the policy/configuration handling
as part of that.
There are three principles that governed the design of ConnMan from a user
interaction perspective. The first is to ask users "only questions
they can answer". If there are questions that a user will have
trouble answering, the program should try to figure them out for itself.
For example, users don't know or care about the various kinds of wireless
keys required, so don't ask a bunch of technical questions about WEP
vs. WPA vs. pre-shared keys, just ask for the password for the wireless
network. The underlying connection manager should recognize what type is
required by the wireless network automatically.
The second is to only show current and valid information to the user so
that they aren't overwhelmed with useless information. Don't tell them
that the Ethernet cable is not plugged in, he said, "they are sitting
in front of it". Hide WiFi networks that have too weak of a signal
rather than showing a bunch of "<unknown>" access points. The emphasis
should be on previous connections that the user has made, because the
chances that "the user wants to use it again are really high".
Lastly, interact with the user only when it's needed. Part of the solution
is to remember things from previous connections and configurations, but
there is more. If ConnMan doesn't make connections quickly enough, users
will start to think something is wrong and start "messing with
things". Also, use error notifications to tell the user something
useful, not just propagating the error message from the underlying code.
It was difficult to keep to the principles, Holtmann said, but that was the
In keeping with the last principle, ConnMan has done some things
differently to try to reduce the time it takes to establish a
As Holtmann mentioned earlier, connection establishment for IP is rather
complicated with multiple pieces required to get to a point where
applications can start using the internet. First there is the low-level
IPv4 and IPv6 address and proxy configuration (which includes DHCP, web
proxy auto-discovery (WPAD), and IPv6 auto-configuration). After that,
it may need to do a WISPr (wireless internet service provider roaming)
hotspot login, followed by time synchronization.
That all takes a fair amount of time largely because of various
inefficiencies in the current implementations. For one thing, IPv4 and
IPv6 discovery and configuration should be done in parallel, rather than
serially. Arbitrary timeouts should also be eliminated.
One of the biggest problem areas was DHCP. In current Linux systems, there
are multiple levels of D-Bus messages and callout scripts to handle DHCP.
There are at least three script/program executions and 2 D-Bus
with arbitrary waits between them, to handle getting an address via
DHCP. "Time is just wasted",
But DHCP only requires 4 UDP messages
of 300-600 bytes each, which "can be done a lot faster than you
think", he said. ConnMan implemented its own DHCP library that
significantly reduced the amount of time it took to get an IP address,
while also reducing memory consumption. The time reduction results in
"approximately 1-2 seconds that can be given back to users",
while the runtime memory savings is very important for some embedded devices.
The feature list for ConnMan is quite large already, and Holtmann went
through a laundry list of them. Obviously, support for WiFi, Bluetooth,
Ethernet, and WiMAX are "have to have" features, he said, but
ConnMan provides quite a bit more than just the connectivity options.
There are various low-level features that were mentioned earlier like DHCP
(both client and server), WPAD and WISPr, and support for timezone
switching. In addition, support for iptables, 6to4 tunnels, DNS
resolver and proxy/cache, an HTTP client, tethering support, and more are
available. There is also a "personal firewall" feature that is
"under discussion right now", he said.
Beyond that, there are two different APIs available for different kinds of
applications to use. The Service API is for configuration and is used by
the ConnMan UI. It unifies the configuration for all of the different connection
options (WiFi, Bluetooth, etc.) as well as providing a single
The Session API is meant for applications to use to
monitor the internet connection. Each application can have one or more
sessions that correspond to different connections they are making. The API
provides IP address change notifications, so that the application can
transparently reconnect. It also allows applications to give priority
information regarding how quickly its data needs to be handled (for "realtime" audio
vs. background network syncing for example). It was designed with
handset and in-vehicle-infotainment (IVI) needs in mind, Holtmann said.
Hotspot login "drove me crazy for a really long time", he
said, but ConnMan now has WISPr 1.0 support that works correctly, unlike
many other implementations (including the iPhone). It doesn't use a browser but does require an
HTTP client. With ConnMan, a device can roam between different
WISPr-supporting hotspots using a password agent to provide the proper
ConnMan also supports WISPr 2.0, but none of the hotspot providers do, so
he has been unable to test it. This will support "real" WiFi offloading,
and it doesn't require a username/password because the SIM card credentials
are used to authenticate.
Proxy support is another problem area that has been solved in ConnMan,
Holtmann said. A user's device may need a proxy to reach the internet when
they are at work and either need a different proxy or none at all when at
home. Changing proxies is difficult to do under Linux, he said. Proxy
solution was needed.
PAC files can be large (he mentioned Intel's being 4M) and must be
downloaded each time a connection is made on networks that use it. To
avoid each application requiring its own PAC support, ConnMan centralizes
that information, but calls out over D-Bus to the pacrunner daemon
to get the required configuration. The implementation is "a little
bit nasty, but it works pretty well" in practice, he said, and it
alleviates users from having to fiddle with proxy configuration.
Full Network Time Protocol (NTP) support is really only needed for
data centers, so ConnMan uses Simple NTP (SNTP) instead. That reduced the
footprint and external dependencies required while still providing
reasonable time synchronization.
ConnMan had full support for tethering via USB, WiFi, and Bluetooth before
either Android or iOS, Holtmann said. It integrates with wpa_supplicant,
BlueZ, and the USB gadget subsystem. In addition,
there is internal iptables handling
as well as DHCP and DNS proxy handling support for ConnMan tethering.
The final feature that Holtmann described is the statistics gathering for
ConnMan. Different connection types have different limits, especially when
roaming, so it is important for users to know what they have used. Also,
some connection types should only be allowed for certain applications, he
said. IVI systems may have a SIM, but the car manufacturer may only want
that used for certain critical functions (navigation, system updates,
etc.). There is Session API support for per-application statistics, but
there is still more work to do on that.
In answer to audience
questions, Holtmann noted that MeeGo is the driving force behind ConnMan,
but that others use it too, including the GENIVI Alliance for IVI
applications as well
as manufacturers of other small embedded Linux devices. ChromeOS uses a
ConnMan that was forked over a year ago—which is a bit surprising:
"do they want the new features or not?". For those who
want to try it on the desktop, he said that Ubuntu is the
only regular distribution that currently has ConnMan packages.
In summary, ConnMan is "fast and simple" and does what users
expect it to do, Holtmann said. The Session API is unique to ConnMan as
far as he knows, and will be very useful to applications. There will be more advanced
features coming in the future, he said. Overall, Holtmann made a pretty
compelling argument for looking at ConnMan as an alternative to
NetworkManager (though he largely avoided talking about the latter),
especially for the mobile device use-cases that it targets.
[ I would like to thank the Linux Foundation for travel assistance to
attend LinuxCon. ]
to post comments)