Announcing ConnMan.net [LWN.net]

Announcing ConnMan.net

Posted Jun 23, 2009 19:36 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Parent article: Announcing ConnMan.net

Why do we need ANOTHER network manager if NetworkManager is now fairly acceptable?

Ok, another question. Will ConnMan integrate with Debian/Ubuntu native network configuration system (i.e. '/etc/network', ifup/ifdown)?

to post comments

Announcing ConnMan.net

Posted Jun 23, 2009 19:45 UTC (Tue) by mitchskin (subscriber, #32405) [Link] (10 responses)

I had this same question. I think part of the rationale for ConnMan is that it can be used earlier in the boot process than NetworkManager, but beyond that I don't understand the details.

I've been hoping for a ConnMan-NetworkManager controversy so that we can all follow it and understand the arguments a bit better. Maybe this is fertile ground for a LWN article?

Announcing ConnMan.net

Posted Jun 23, 2009 21:36 UTC (Tue) by leoc (guest, #39773) [Link] (9 responses)

Seconded! It is not clear to me from the available information what exactly precluded the projects from working together.

Announcing ConnMan.net

Posted Jun 23, 2009 22:44 UTC (Tue) by njs (subscriber, #40338) [Link] (8 responses)

These slides explicitly contrast ConnMan and Network Manager:
http://moblin.org/sites/all/files/lfcs2009-connman.pdf

Their direct critique of Network Manager isn't very convincing. Apparently NM has a "large dependency list", which in practice just seems to mean that ConnMan wrote their own glib/dbus integration instead of using libdbus-glib? I dunno. There's "too much GNOME like source code". If you say so, I guess? The diagram on slide 6 looks scary on first glance, but then compare to slide 14 (interesting example of how to use diagram layout to make a rhetorical point, though)... Basically it looks like they hadn't thought about this very hard so they just wrote a list of the standard complaints people make about every project, and some of them may be valid but they don't really justify rewriting things from scratch.

Which is fine -- they do a much better job of talking about what they actually do want to do, and they have some interesting and new ideas about how to architect a connection manager. The main points seem to be: 1) general cleanup and cruft removal, 2) move all logic into the daemon and make the UI just a trivial "thin client" display layer, 3) be "heavier-weight" (contrary to their earlier rhetoric!) in the sense of unifying more aspects of network management (DNS, HTTP proxy, Zeroconf, etc.) into a single address space so that they can be done more intelligently.

They definitely have some potentially good ideas; it'll be interesting to see which ones work out, and whether they survive as a project or just force Network Manager to implement the good parts themselves :-).

Announcing ConnMan.net

Posted Jun 24, 2009 8:55 UTC (Wed) by danpb (subscriber, #4831) [Link] (7 responses)

The points the ConnMan PDF raises against NetworkManager were all valid criticisms of the 0.6.x release series of NM, but none of them were fundamentally unfixable flaws. Indeed this is highlighted by the fact that a great many of the 'problems' were addressed in the 0.7.0 series of NM. So I can't help thinking the decision to start writing from scratch was not the most effective use of resources.

Announcing ConnMan.net

Posted Jun 24, 2009 14:44 UTC (Wed) by wstephenson (guest, #14795) [Link] (6 responses)

Try implementing a NetworkManager 0.7 client then. There is still a lot of boring work every client has to do to make the objects NM exposes on the bus into something that the user can interact with.

Announcing ConnMan.net

Posted Jun 24, 2009 16:11 UTC (Wed) by nirik (subscriber, #71) [Link] (4 responses)

cnetworkmanager?

http://vidner.net/martin/software/cnetworkmanager/

Announcing ConnMan.net

Posted Jun 24, 2009 16:20 UTC (Wed) by wstephenson (guest, #14795) [Link] (3 responses)

Martin's client is great for what it does, for example if you just want to connect to a WPA-PSK network from the command line, but it's very limited.
I meant a full-featured client that starts with the desktop session, saves configuration to disk (and securely where appropriate) and has a UI.

Announcing ConnMan.net

Posted Jun 24, 2009 16:28 UTC (Wed) by dcbw (guest, #50562) [Link] (2 responses)

Of course this takes some code, just like for example writing a usable display configuration applet that handles monitor hotplug and removal, configuration-on-the-fly, saved settings, etc. When you're dealing with hardware and configuration, you need to write the code to deal with that hardware and all the configuration options.

But since you've implemented the plasma stuff, I'm curious what your suggestions would be for making it easer. How can the D-Bus interface be improved? What can be made simpler, ensuring that the flexibility of the configuration system is retained?

It would be a lot simpler if we could get rid of ActiveConnection and just use the Device object, but unfortunately, we're just about to add bridging support, and that's going to make the ActiveConnection class have more than one device in the "Devices" property.

Networking is a complex problem, and if you want to solve users' needs, you often need to write non-trivial amounts of code to make sure it's possible and easy for the user. Often that means it's harder for the develoepr.

Announcing ConnMan.net

Posted Jun 24, 2009 16:47 UTC (Wed) by wstephenson (guest, #14795) [Link] (1 responses)

The simplifying approach I've taken for KDE, to make it possible for non-NM specialists to work on the GUI, is to produce a high level flat list of "things that the user might want to click"

1) Wireless networks (as the NM dbus api only gives a list of access points)
2) Connection on an Interface.

This list is pre-filtered on appropriateness (a fuzzy definition but you know what I mean - don't list any connections where a matching AP is not visible - don't list wired connections when there is no cable inserted, don't show anything wireless when in flight mode, etc).

From what I've read of the ConnMan docs so far, they have taken a similar approach in what is presented to the client, giving up some correctness and flexibility in the model (at that layer) for ease of use.

Announcing ConnMan.net

Posted Jun 24, 2009 18:27 UTC (Wed) by dcbw (guest, #50562) [Link]

You'll probably remember that NM 0.6 did group "networks" together for you. That turned out to be a huge mistake in the daemon, because you need to separate networks based on SSID, capabilities, and band. Unfortunately, trying to over-simplify things is exactly what caused problems with NetworkManager 0.6, since you simply cannot trust people to actually name their access points reliably. Thus you end up with situations where you have two APs called 'linksys' with different security settings, and the user wants to connect to the higher-security one, but not the lower-security one. Or, their linksys AP is on the A-band, but their neighbors is on the B/G band.

Similarly, we found that *not* showing interfaces that were disabled or not managed by NM caused *huge* numbers of bug reports, mostly from Ubuntu users asking "where's my wifi card" when Ubuntu set their wifi card unmanaged by default and it disappeared from the applet.

So the gnome applet tries to give you an informed view of your machine, including why you can't do some things you may want to, instead of just hiding those items completely. The same reason why menu items get disabled rather than hidden outright.

Announcing ConnMan.net

Posted Jun 24, 2009 16:24 UTC (Wed) by dcbw (guest, #50562) [Link]

That's only if you want to implement user-specific connections like the applet does, which are completely optional. If you simply want to use system connections, which are handled entirely by NetworkManager, then you don't need to be a service on the bus at all. That's 66% of what nm-applet is doing; if you strip that out, it's really just some dbus calls and a GtkMenu. I should really write a minimal client just to dispel this sort of FUD.

I'm curious about the "boring work" you refer to. Using a library that makes it easy for you like libnm-glib, or by using python, it's pretty darn easy. But for a UI to be usable, you still need to ensure that you don't show the user things which aren't applicable to their situation, do proper error checking and notification, handle device removal and insertion, device status changes, etc.

I think you're expecting the problem to be simple, but it's not, and that's not NetworkManager's fault.

Announcing ConnMan.net

Posted Jun 23, 2009 20:08 UTC (Tue) by MrWim (subscriber, #47432) [Link]

I was wondering the same thing. I've found two links that seem to be statements of intent rather than actual reports of progress:
http://repo.moblin.org/connman/docs/connman-lk2008.pdf
http://lists.moblin.org/pipermail/connman/2008-December/0...

And also an ubuntu wiki page comparing them (unsure of neutrality):
https://wiki.ubuntu.com/DesktopTeam/ConnectionManagerComp...

Announcing ConnMan.net

Posted Jun 23, 2009 20:43 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

network manager acceptable????

I agree that it seems to work for many people, but it also fails to work for many people.

to me it seems to work in the simple case and fail utterly in a more complex case (and in the process of failing makes it _very_ hard to work around it)

I ended up uninstalling it this last week bacause I couldn't get it to stay connected to the wireless network in the hotel I was staying in for more than a couple of min, once I got it completely uninstalled and configured the wireless info into /etc/networks/interfaces (debian derived system) the wireless access was rock-solid.

Announcing ConnMan.net

Posted Jun 24, 2009 16:32 UTC (Wed) by dcbw (guest, #50562) [Link]

This usually means your driver sucks, and the supplicant isn't able to hold a connection. The driver was likely bouncing around and failing to associate periodically.

People always complain with WEP and unencrypted networks that "it works fine with iwconfig", but for some reason not with NM. NM uses wpa_supplicant, which expects a lot more out of drivers than iwconfig does. The plain fact is that if the driver can't handle WEP or unencrypted operation with wpa_supplicant, it's broken and it needs to be fixed.

Blaming NetworkManager for that is like blaming the inability of your laptop to hibernate on the Shutdown/Sleep dialog. It's not the cause of the problem. The drivers are.

NetworkManager pushes those drivers to work better, and many many driver bugs have been fixed because NetworkManager did that. It would be great if you'd file a bug so we can track down what is the problem with your driver and fix it.

Announcing ConnMan.net

Posted Jun 23, 2009 21:11 UTC (Tue) by Tcler (guest, #5919) [Link] (1 responses)

From what I understand the main motivation is that NetworkManager has way too many dependencies. It requires installation of a lot of other tools that aren't necessarily desirable in a smartphone, MID, or other small form factor device.

Announcing ConnMan.net

Posted Jun 23, 2009 22:41 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

cyberax@devsrv:~/work/app$ apt-cache depends network-manager
network-manager
Depends: libc6
Depends: libdbus-1-3
Depends: libdbus-glib-1-2
Depends: libglib2.0-0
Depends: libhal1
Depends: libnl1
Depends: libnm-glib0
Depends: libnm-util1
Depends: libnspr4-0d
Depends: libnss3-1d
Depends: libpolkit-dbus2
Depends: libpolkit2
Depends: libudev0
Depends: libuuid1
Depends: iproute
Depends: iputils-arping
Depends: lsb-base
Depends: wpasupplicant
Depends: dbus
Depends: hal
Depends: update-notifier-common
Depends: ppp

I don't really see too many dependencies. Well, update-notifier-common probably can be dropped. Almost everything else is already used on Moblin.

Probably, we have yet another severe case of NIH.

Announcing ConnMan.net

Posted Jun 24, 2009 0:09 UTC (Wed) by landman (guest, #2901) [Link] (10 responses)

NetworkManager is non-usable on most of the machines we deal with. One of the very first actions I do after installing a system is to replace NetworkManager with wicd. The latter works, in expected ways, with no surprises. The former? Not so much. On laptops with WPA2 PSK, we get exactly one connection to the Wifi. Second connection never works, even if you re-enter the key.

I no longer even waste my time with it. Wicd gets installed immediately after OS load for portable machines that have to connect via wireless/wired interfaces.

Not sure if ConnMan will be better or worse than NetworkManager. Don't care. Wicd works. Very well.

Announcing ConnMan.net

Posted Jun 24, 2009 2:31 UTC (Wed) by njs (subscriber, #40338) [Link] (7 responses)

I know it's fashionable to post these rants about how some random piece of popular desktop software is a piece of junk, but seriously... what does one niggly (but I'm sure very frustrating) NetworkManager bug have to do with ConnMan.net? More generally, how does this kind of post make LWN a more wonderful place?

Announcing ConnMan.net

Posted Jun 24, 2009 5:59 UTC (Wed) by Cato (guest, #7643) [Link] (3 responses)

The grandparent post was on-topic and quite useful - I have the same experience with Network Manager and end up using wicd as well, and I've seen quite a lot of discussion of this. wicd is also more appropriate for low-end machines with less than 200 MB RAM.

Announcing ConnMan.net

Posted Jun 24, 2009 16:54 UTC (Wed) by drag (guest, #31333) [Link]

The one time I tried wicd it made my eyes bleed. I don't know how somebody could possibly recommend it over network-manager except on very low resource machines.. and even then I think that just using the default Debian network configuration scripts would be superior.

I think that most people are basing their impressions on Network-Manager 0.6 stuff, which was abismal. The 0.7.1 is vastly superior in all respects.

I have yet to run into any way other then Network-Manager to make using a tethered phone, 3G network adapter, or anything of that nature even remotely usable in Linux*.

I wouldn't mind seeing a better more modular solution then NM. If somebody had a very nice command line client for NM then that would be terrific. Maybe Conman will be better since it seems to be designed for small devices like Cell phones and whatnot.

But so far nothing I've seen comes close to trying to fix the problems NM is trying to fix.

* and if any solution anybody is using involves ppp your solution sucks.. modern devices don't work like that anymore and if they can be configured through ppp and chat scripts then that means that it's in 'legacy' mode and performance and reliability will suffer.

Announcing ConnMan.net

Posted Jun 25, 2009 9:34 UTC (Thu) by mbiebl (subscriber, #41876) [Link] (1 responses)

You are aware that wicd is implemented in python?
How does that make it more appropriate for low-end machines?
/me being puzzled

Announcing ConnMan.net

Posted Jun 25, 2009 17:53 UTC (Thu) by walters (subscriber, #7396) [Link]

Because basically no one does any actual measurement, they just believe and repeat what's been written by some guy on some website (often without instructions to reproduce).

Or they equate say a list of library dependencies with memory use, when in the real world it's very likely user interface strings, images, or plain old memory leaks that are actually using memory.

Announcing ConnMan.net

Posted Jun 24, 2009 6:44 UTC (Wed) by dlang (guest, #313) [Link] (2 responses)

remember that this was in response to the initial 'Network Manager exists and does everything you would need, why would anyone bother to duplicate this work' post.

it's one more comment to show that Network Manager doesn't work for everyone, so there definantly is room for alternate implementations of the same basic idea

Announcing ConnMan.net

Posted Jun 24, 2009 9:27 UTC (Wed) by njs (subscriber, #40338) [Link] (1 responses)

> it's one more comment to show that Network Manager doesn't work for everyone, so there definantly is room for alternate implementations of the same basic idea

But the conclusion doesn't follow. Unpacking, the argument seems to be: "Even after huge amounts of testing and debugging by all major distros, NetworkManager is not 100% bug-free in all configurations. Therefore, we should throw out all the code and experience that went into making it what the original poster calls 'fairly acceptable', and start over from scratch."

Don't get me wrong, I'm perfectly happy for people to play around with different approaches to solving this problem, there are good arguments for doing so, I'm glad wicd works for people, whatever. And I probably should have followed my first impulse and ignored that post as a bit of regrettable but inevitable noise. But I keep seeing these posts that are basically just HEY GUYS GUESS WHAT THIS SOFTWARE HAS BUGS without anything to tickle the reader's intellect, and what's the point?

(Not that this post has a leg to stand on there!)

Announcing ConnMan.net

Posted Jun 25, 2009 11:21 UTC (Thu) by marcH (subscriber, #57642) [Link]

> Unpacking, the argument seems to be: "Even after huge amounts of testing and debugging by all major distros, NetworkManager is not 100% bug-free in all configurations. Therefore, we should throw out all the code and experience that went into making it what the original poster calls 'fairly acceptable', and start over from scratch."

I unpacked something slightly different, making much more sense. But of course perception is subjective.

"After huge amounts of testing and code review, NetworkManager has too many bugs and design limitations and these are too hard to fix. So let us start from scratch, after of course learning from its mistakes".

I am not saying this is true, but it does make sense.

Announcing ConnMan.net

Posted Jun 24, 2009 16:35 UTC (Wed) by dcbw (guest, #50562) [Link]

So is your driver bouncing around and unable to hold a stable connection? Is the access point and network randomly failing to reassociate? What driver do you have? Can you provide some logs from /var/log/messages or /var/log/daemon.log that show the problem so we can diagnose it?

The "second time problem" is almost always a case of driver bugs or supplicant bugs. If you can connect again after you 'killall -TERM wpa_supplicant' or 'rmmod <your driver>', then you've found the source of your problem, and that's where it should be fixed.

Announcing ConnMan.net

Posted Jun 25, 2009 16:05 UTC (Thu) by ssam (guest, #46587) [Link]

when was the last time you tried NM, maybe your bug is fixed. have you reported the issue to the devs?

Announcing ConnMan.net

Posted Jun 24, 2009 11:48 UTC (Wed) by enberg (guest, #30512) [Link] (10 responses)

With some luck, Connman will actually be documented. It's long been my ambition to write a working terminal ui for Networkmanager, but every time I've sat down to look at it I've been stymied by no docs and a twisty maze of strange dbus calls.

Announcing ConnMan.net

Posted Jun 24, 2009 13:33 UTC (Wed) by johill (subscriber, #25196) [Link] (2 responses)

http://code.google.com/p/network-manager-cli/ ?

Announcing ConnMan.net

Posted Jun 24, 2009 13:50 UTC (Wed) by enberg (guest, #30512) [Link] (1 responses)

Unfortunately, that's for an outdated version of NetworkManager, the current nm 0.7 series completely changed the API.

Announcing ConnMan.net

Posted Jun 24, 2009 16:10 UTC (Wed) by nirik (subscriber, #71) [Link]

Try cnetworkmanager?

http://vidner.net/martin/software/cnetworkmanager/

Announcing ConnMan.net

Posted Jun 24, 2009 14:43 UTC (Wed) by dcbw (guest, #50562) [Link] (4 responses)

Is there something wrong with http://projects.gnome.org/NetworkManager/developers/spec.... ? It's a full description of the D-Bus API. Most of libnm-glib is also documented. Much of libnm-util is as well. Of course more documentation is needed, both in the code and for usage of the D-Bus interface. However, I'd think that nm-tool would give you a pretty good idea of how to use it via libnm-glib, and it's also simple via Python if you take a look at the dbus spec.

Announcing ConnMan.net

Posted Jun 24, 2009 16:33 UTC (Wed) by wstephenson (guest, #14795) [Link] (3 responses)

http://live.gnome.org/NetworkManagerConfigurationSpecific... is necessary to know too, but is incomplete in many ways, so all roads lead back to grokking the NM daemon and gnome client code.

Announcing ConnMan.net

Posted Jun 24, 2009 16:36 UTC (Wed) by dcbw (guest, #50562) [Link] (2 responses)

I assume you mean the lack of the documentation of the key/value pairs for configuration? That's a valid criticism, but it's being fixed by documenting libnm-util.

What other ways is it "incomplete"?

Announcing ConnMan.net

Posted Jun 24, 2009 16:59 UTC (Wed) by wstephenson (guest, #14795) [Link] (1 responses)

Generally a Big Picture of how NM configuration works is missing.

Re the config key/values:
Groups like pppoe are missing.
The dependencies between settings groups to make NM accept a connection.
Lots of details of the significance of the values, for example the need for clients to keep seen-bssids updated for autoconnect to work, and the timestamp's role in choosing which connection to autoconnect.

Announcing ConnMan.net

Posted Jun 24, 2009 18:29 UTC (Wed) by dcbw (guest, #50562) [Link]

All valid points. The documentation does need to be a lot better, that's true, and that's something that we've been trying to make a better effort on in the past 6 months or so.

Announcing ConnMan.net

Posted Jun 24, 2009 16:22 UTC (Wed) by wstephenson (guest, #14795) [Link] (1 responses)

Ahah, welcome to my life! I've threaded the NetworkMinotaur's labyrinth while working on KNetworkManager. Swing by #solid on freenode if you want me explain things.

Announcing ConnMan.net

Posted Jun 24, 2009 16:37 UTC (Wed) by dcbw (guest, #50562) [Link]

Or, we could have a constructive discussion about how to improve NetworkManager somewhere that everyone can have input, instead of on a channel that not everyone is on.