Announcing ConnMan.net
| From: | Marcel Holtmann <holtmann-AT-linux.intel.com> | |
| To: | lwn-AT-lwn.net | |
| Subject: | Announcing ConnMan.net | |
| Date: | Tue, 23 Jun 2009 18:43:38 +0200 | |
| Message-ID: | <1245775418.15367.106.camel@violet> | |
| Cc: | jukka.rissanen-AT-nokia.com |
Intel and Nokia are pleased to jointly launch the ConnMan project, an open source project to accelerate and expand development of Internet connection management for Linux Devices. ConnMan will be utilized as a technology within Moblin and Maemo. Connman.net is now the place to bring developers together who are interested in furthering the development of Internet connection management within Linux. Review the source code for more information. ConnMan is licensed under GPLv2, and provides a daemon for managing Internet connections within Linux devices. ConnMan is a fully modular system that can be extended, through plugins, to support all kinds of wired or wireless technologies. Configuration methods, like DHCP and domain name resolving, are implemented using plug-ins as well. The plug-in approach allows for easy adaption and modification for various use cases. Nokia and Intel will jointly maintain the ConnMan project. We'd like to invite all developers to join the connman.net effort and community. Marcel Holtmann, Intel Open Source Technology Center Jukka Rissanen, Nokia Devices, Maemo Software
Posted Jun 23, 2009 19:36 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (38 responses)
Ok, another question. Will ConnMan integrate with Debian/Ubuntu native network configuration system (i.e. '/etc/network', ifup/ifdown)?
Posted Jun 23, 2009 19:45 UTC (Tue)
by mitchskin (subscriber, #32405)
[Link] (10 responses)
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?
Posted Jun 23, 2009 21:36 UTC (Tue)
by leoc (guest, #39773)
[Link] (9 responses)
Posted Jun 23, 2009 22:44 UTC (Tue)
by njs (subscriber, #40338)
[Link] (8 responses)
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 :-).
Posted Jun 24, 2009 8:55 UTC (Wed)
by danpb (subscriber, #4831)
[Link] (7 responses)
Posted Jun 24, 2009 14:44 UTC (Wed)
by wstephenson (guest, #14795)
[Link] (6 responses)
Posted Jun 24, 2009 16:11 UTC (Wed)
by nirik (subscriber, #71)
[Link] (4 responses)
Posted Jun 24, 2009 16:20 UTC (Wed)
by wstephenson (guest, #14795)
[Link] (3 responses)
Posted Jun 24, 2009 16:28 UTC (Wed)
by dcbw (guest, #50562)
[Link] (2 responses)
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.
Posted Jun 24, 2009 16:47 UTC (Wed)
by wstephenson (guest, #14795)
[Link] (1 responses)
1) Wireless networks (as the NM dbus api only gives a list of access points)
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.
Posted Jun 24, 2009 18:27 UTC (Wed)
by dcbw (guest, #50562)
[Link]
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.
Posted Jun 24, 2009 16:24 UTC (Wed)
by dcbw (guest, #50562)
[Link]
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.
Posted Jun 23, 2009 20:08 UTC (Tue)
by MrWim (subscriber, #47432)
[Link]
And also an ubuntu wiki page comparing them (unsure of neutrality):
Posted Jun 23, 2009 20:43 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
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.
Posted Jun 24, 2009 16:32 UTC (Wed)
by dcbw (guest, #50562)
[Link]
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.
Posted Jun 23, 2009 21:11 UTC (Tue)
by Tcler (guest, #5919)
[Link] (1 responses)
Posted Jun 23, 2009 22:41 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
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.
Posted Jun 24, 2009 0:09 UTC (Wed)
by landman (subscriber, #2901)
[Link] (10 responses)
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.
Posted Jun 24, 2009 2:31 UTC (Wed)
by njs (subscriber, #40338)
[Link] (7 responses)
Posted Jun 24, 2009 5:59 UTC (Wed)
by Cato (guest, #7643)
[Link] (3 responses)
Posted Jun 24, 2009 16:54 UTC (Wed)
by drag (guest, #31333)
[Link]
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.
Posted Jun 25, 2009 9:34 UTC (Thu)
by mbiebl (subscriber, #41876)
[Link] (1 responses)
Posted Jun 25, 2009 17:53 UTC (Thu)
by walters (subscriber, #7396)
[Link]
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.
Posted Jun 24, 2009 6:44 UTC (Wed)
by dlang (guest, #313)
[Link] (2 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
Posted Jun 24, 2009 9:27 UTC (Wed)
by njs (subscriber, #40338)
[Link] (1 responses)
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!)
Posted Jun 25, 2009 11:21 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
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.
Posted Jun 24, 2009 16:35 UTC (Wed)
by dcbw (guest, #50562)
[Link]
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.
Posted Jun 25, 2009 16:05 UTC (Thu)
by ssam (guest, #46587)
[Link]
Posted Jun 24, 2009 11:48 UTC (Wed)
by enberg (guest, #30512)
[Link] (10 responses)
Posted Jun 24, 2009 13:33 UTC (Wed)
by johill (subscriber, #25196)
[Link] (2 responses)
Posted Jun 24, 2009 13:50 UTC (Wed)
by enberg (guest, #30512)
[Link] (1 responses)
Posted Jun 24, 2009 16:10 UTC (Wed)
by nirik (subscriber, #71)
[Link]
Posted Jun 24, 2009 14:43 UTC (Wed)
by dcbw (guest, #50562)
[Link] (4 responses)
Posted Jun 24, 2009 16:33 UTC (Wed)
by wstephenson (guest, #14795)
[Link] (3 responses)
Posted Jun 24, 2009 16:36 UTC (Wed)
by dcbw (guest, #50562)
[Link] (2 responses)
What other ways is it "incomplete"?
Posted Jun 24, 2009 16:59 UTC (Wed)
by wstephenson (guest, #14795)
[Link] (1 responses)
Re the config key/values:
Posted Jun 24, 2009 18:29 UTC (Wed)
by dcbw (guest, #50562)
[Link]
Posted Jun 24, 2009 16:22 UTC (Wed)
by wstephenson (guest, #14795)
[Link] (1 responses)
Posted Jun 24, 2009 16:37 UTC (Wed)
by dcbw (guest, #50562)
[Link]
Posted Jun 23, 2009 20:47 UTC (Tue)
by asdlfiui788b (guest, #58839)
[Link]
Posted Jun 23, 2009 22:14 UTC (Tue)
by andrel (guest, #5166)
[Link] (2 responses)
Posted Jun 23, 2009 23:48 UTC (Tue)
by Kit (guest, #55925)
[Link]
(but yeah, I *really* don't like the name because of the images it invokes...)
Posted Jun 24, 2009 0:53 UTC (Wed)
by wmf (guest, #33791)
[Link]
Posted Jun 24, 2009 13:46 UTC (Wed)
by fray (subscriber, #5577)
[Link] (3 responses)
However, in an embedded Linux context (this cell phone, MID device, automotive applications, etc.) things that control networking need to be much more automated and policy based then Network Manager allows.
Also remember in many embedded devices user control/display of network settings is simply not done, or not allowed by policy.
If ConnMan can meet the requirements of the embedded linux area's it is targeting _AND_ replace Network Manager, I think this would be a huge win for all Linux users.
Posted Jun 24, 2009 14:40 UTC (Wed)
by dcbw (guest, #50562)
[Link] (2 responses)
"Also remember in many embedded devices user control/display of network settings is simply not done, or not allowed by policy."
Why is this relevant? NetworkManager does *NOT* require a UI to operate. It is completely controllable via D-Bus, like ConnMan.
There's nothing stopping NetworkManager from being used on netbooks and MIDs. It's already being used there. There's nothing to stop it from being used on embedded devices too, except FUD.
Posted Jun 25, 2009 16:30 UTC (Thu)
by nlucas (guest, #33793)
[Link] (1 responses)
But, as soon as you depend on d-bus/glib you are already out of the embedded space.
Posted Jun 25, 2009 17:43 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
Posted Jun 25, 2009 16:02 UTC (Thu)
by ssam (guest, #46587)
[Link]
there are some odd cases, eg a laptop whos MAC address would change after resuming from sleep (some sort of hardware weirdness that the kernel did not work around or a kernel bug or something), but the network identified machines by MAC address. NM does not have an option to set the MAC address so i had to add a hackish script. i dont see how creating a new system from scratch is going to fix this, or is the best way to fix this.
with regards to wicd: you here a few 'NM did not work, so i switched to wicd and that worked'. i wonder what would happen if wicd was installed by default. from my experience NM works in over 90% of cases (excluding wifi card with no driver at all). suppose that wicd works in some of the 10% of case where NM fails. if you wicd was default, would it really work in more cases than NM?
ps: people should have a look at this http://blogs.gnome.org/dcbw/2009/06/25/networkmanager-and...
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
http://moblin.org/sites/all/files/lfcs2009-connman.pdf
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
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
Announcing ConnMan.net
2) Connection on an Interface.
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
http://repo.moblin.org/connman/docs/connman-lk2008.pdf
http://lists.moblin.org/pipermail/connman/2008-December/0...
https://wiki.ubuntu.com/DesktopTeam/ConnectionManagerComp...
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
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
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
How does that make it more appropriate for low-end machines?
/me being puzzled
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
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
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Ugh, another lousy project name
Ugh, another lousy project name
Ugh, another lousy project name
"Dirty Rotten Scoundrels" release myself.
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net
Announcing ConnMan.net