Lately ofono and ConnMan have been in the news, and that’s sparked some discussion about how these two projects relate to NetworkManager. I’ve mostly just been ignoring that discussion and focusing on making NetworkManager better. But at some point the discussion needs to become informed and the facts need to be straightened out.
So what makes NetworkManager great?
- Flexibility: NM’s D-Bus interface provides a ton of control and information about the network connections of your machine. Developers and applications simply don’t take enough advantage of this. Imagine mail automatically pulled whenever the corporate VPN is up. Or more restrictive firewalls when connected to public networks. Yeah, you can do that today with NetworkManager.
- Works everywhere: from the mainframe to the power desktop to the netbook and lower. There’s nothing stopping you from running NetworkManager on an s390 or a Palm Pre.
- Integration: most users like NetworkManager’s distro integration, so it’s on by default (but can be turned off for running bare-metal). NM will read your distro’s network config files: ifcfg on Fedora, /etc/network/interfaces on Debian, etc. It doesn’t pretend the rest of the world doesn’t exist, but it can if you tell it to.
- Connection Sharing: you can share your 3G connection to the wired or the wifi interface, or the other way around. How you share is completely up to you.
- VPN: it’s got plugins for Cisco (vpnc), openvpn, openconnect, and pptp. An ipsec/openswan plugin is being written. It’s just easy to use the VPN of your choice.
- Makes Linux better: by not working around stupid vendor drivers or other broken components, NetworkManager drives many improvements in drivers, kernel APIs, the supplicant, and desktop applications. Five years ago I posted a list of wifi problems, many of which got fixed because NetworkManager users complained about them. Stuff like WPA capability fixes, hidden SSID fixes, suspend/resume improvements, Ad-Hoc mode fixes, and lots of improvements to wpa_supplicant to name just a few. By encouraging drivers to be open, by fixing bugs in the open drivers and the stack instead of hacking around them, and by encouraging vendors to work upstream, NetworkManager makes Linux better for you.
What great stuff is coming next?
All in all, a lot of great stuff is on the plate. NetworkManager already works well for a ton of people, but we’d like to make it work better for a lot more people. And it will.
So what about ConnMan?
I recently came across a slide deck about ConnMan which makes both disappointing and inaccurate claims about NetworkManager. It’s also worth emphasizing the philosophical differences between the two projects.
First, ConnMan primarily targets embedded devices, netbooks, and MIDs (slide #1). When ConnMan was first released in early 2008, NetworkManager 0.7 was under heavy development, and NetworkManager 0.6 clearly did not meet the requirements. But 0.7, released in November 2008, works well for a wide range of use-cases and hardware platforms.
NetworkManager scales from netbooks, MIDs, and embedded devices with custom-written UIs to desktops to large systems like IBM’s s390. You get the best of both worlds: from phenomenal cosmic power down to itty-bitty living space.
ConnMan explicitly doesn’t try to integrate with existing distributions (slide #5), partly due to it’s requirements to be as light-weight as possible. But NetworkManager will use your distro’s normal network config and startup scripts if you tell it to do (but you don’t have to). Early in NetworkManager days we tried to ignore the rest of the world too. Turns out that doesn’t work so well; users demand integration with their distribution. But ConnMan doesn’t pretend to be general purpose, and due to its embedded focus, it can wave this issue away.
Both ConnMan and ofono reject well-established technologies like GObject (but still uses glib) in favor of re-implementing much of GObject internally anyway. This is a curious decision as GObject is not a memory hog and not a performance drag for these cases. The NIH syndrome continues with libgppp, libgdhcp, and libgdbus, where instead of improving existing, widely-used tools like dhclient/dhcpcd, pppd, and dbus-glib, ConnMan opts to re-implement them in the name of being more “lightweight”. With embedded projects that ConnMan targets (like Maemo and Moblin) already using GObject and dhcpcd, I don’t understand why this tradeoff was made. Perhaps this visceral dislike of GObject and dbus-glib was one reason the project’s creators decided to write their own connection manager instead of helping to improve existing ones.
NetworkManager in contrast re-uses and helps improve components all over the Linux stack. Because of that, more people benefit from the fixes and improvements that NetworkManager drives in projects like avahi, wpa_supplicant, the kernel, pppd, glib, dbus-glib, ModemManager, libnl, PolicyKit, udev, etc.
Taking a look at the deck
I have things to say about most of the slides, but I’ll concentrate on the most interesting and misinformed ones instead.
- Very Complex Design: a complete strawman, because it doesn’t say anything. NetworkManager 0.7 is a mature project with many useful features. NM is based around a core of objects, each one performing actions based on signals and events from other objects. It’s modular and flexible. It’s just not a ConnMan-style box of lego blocks with a rigid plugin API and all the problems that causes.
- Large Dependency List: NM requires things like wpa_supplicant, udev, dbus, glib, libuuid, libnl, and a crypto library. pppd and avahi are optional. This list is certainly not large. When you take ConnMan and its optional dependencies (most of which are needed in a useful system) the list is just about the same.
- Too Much Decision-making in the UI: Completely bogus and frankly incomprehensible. The core NM daemon provides a default policy which is in no way connected to the UI, and the rest is up to the user. nm-applet contains no policy whatsoever. If the objection is to nm-applet’s desktop-centric interaction model, then it’s important to know there is no lack of applets for different use-cases.
- Tries to work around distro problems: this is completely a matter of perspective. Since Intel was creating its own Linux distribution (moblin), they didn’t have to work around any existing issues; these were simply waved away. Unfortunately NetworkManager lives in the world of reality and not some universe full of ponies. For users that expect it, NetworkManager integrates with your distros existing network config, init scripts, and DNS resolution. For users that don’t care, NetworkManager can run bare-metal.
- Too much GNOME-like source code: seriously, what the hell? I’m not sure where to begin with this one. The NetworkManager core does not depend on GNOME. At all. Yeah, the source-code is in the Gnome style, but is that seriously an issue?
(Misinformation shaded blue for your protection)
The User Settings service is contained in the applet, and it’s completely optional. The System Settings service has been merged back into the NetworkManager core daemon and is no longer a separate process. That same commit ported NM from HAL to udev; thus HAL is no longer required. NetworkManager always used HAL/udev for device detection instead of RTNL (ie, netlink). NetworkManager also hasn’t used WEXT for a long time; wpa_supplicant handles kernel wireless configuration. NetworkManager uses distro networking scripts only for service control, as does ConnMan. The rest of the slide is quite petty and just splits hairs.
Where to?
It’s unlikely that either NetworkManager or ConnMan will disappear in the near future. That means we’ll all have to live with two mutually exclusive connection managers and two completely different network configuration systems. I think that’s pretty pointless, but I don’t get the last word anyway, since that’s not how Open Source works. The users will decide which solution works best for them. And that means NetworkManager will keep getting better, keep getting more useful, and will continue to be the easiest network management solution around.