LinuxCon: Mobile network management with ConnMan

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.

Design principles

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

Reducing time-to-connect

In keeping with the last principle, ConnMan has done some things differently to try to reduce the time it takes to establish a connection. 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 messages, sometimes with arbitrary waits between them, to handle getting an address via DHCP. "Time is just wasted", Holtmann said.

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.

ConnMan features

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 signal-strength API.

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

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 auto-configuration (PAC) is one solution, but it is JavaScript-based. Since they don't want a JavaScript interpreter in every system, a separate 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 version of 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. ]