Weekly Edition
Return to the Press page
| |||||||||||||
NetworkManager and ConnMan (Dan Williams' Blog)
Dan Williams
discusses the advantages of NetworkManager over ofono and ConnMan
on his blog.
"Lately ofono and ConnMan have been in the news, and thats sparked some discussion about how these two projects relate to NetworkManager. Ive 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? ..."
(Thanks to Paul Wise).
(Log in to post comments)
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 17:43 UTC (Thu) by s0f4r (subscriber, #52284) [Link]
Very one-sided blog post IMHO, very little concrete information on how connman compares to networkmanager in practice. I'd like to see someone show me how they compare in memory footprint, system requirements, supported plugins (afaik connman supports openconnect, openvpn too), etc. Story pulls aside an early PPT and tries to disprove claims in it, instead of actually looking at connman.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 17:49 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
Early? That was presented at the Linux Foundation collaboration summit, which was only a bit over two months ago.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 26, 2009 21:29 UTC (Fri) by s0f4r (subscriber, #52284) [Link]
How old is networkmanager now? Connman is barely out of beta stage and Dan is shooting with long range missiles at it. Frankly, it sounds like he is "scared" of connman to me :)
The fact that Marcel hasn't gotten to writing decent powerpoint presentations and documentation yet (arguably) is not a sign of that connman is evil or in any way mature.
Dan's Blog post is also skewing the comparison by neatly formatting the strong points of NetworkManager, and then making the connman points a homogenous blob of text.
It seems Dan is blog/ranting more against the PPT presentation itself than connman. And (ab)using the same tactics as the one applied in that very PPT: misinformation.
Again, I'd like to see a technical comparison based on facts, not one based on either side's propagande.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 17:53 UTC (Thu) by engla (guest, #47454) [Link]
The slides are from 2009, and were posted on LWN just recently. It seems that the NM author can use it pretty well to boast about NM's major features in application and philosophy, but it really looks like the connman project is struck by NIH syndrome and could take a bash.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 21:22 UTC (Thu) by nhippi (subscriber, #34640) [Link]
The connman author appears definetly belong to the group of Developers that prefer rewriting from scratch over fixing and improving existing stuff. The network-manager/connman combo appears to closely mimic what happened with FSO/ofono. Same way the FSO developers complained that oFono's critique over FSO was misguided.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 17:54 UTC (Thu) by rberger (guest, #52829) [Link]
Can't say much about NM apart from that I use to turn it off, due to it's tendency to tear down network interfaces when resuming from suspend on my Debian desktops.
With standard interface management on the other hand, no hassle at all as far as I can tell. Interfaces are just up and alive each time I resume.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 19:16 UTC (Thu) by dcbw (guest, #50562) [Link]
How long are you suspending for? I don't have issues with resuming my laptop from suspend or hibernate, and NM will automatically connect to my work's wifi when I'm at work, and my home's wifi when I'm at home, or the ethernet when it's plugged in.
Perhaps you're hitting this dbus bug? D-Bus upstream has been somewhat slow in fixing it.
https://bugzilla.redhat.com/show_bug.cgi?id=477964
It would cause NM to think that networking was not enabled on resume from suspend or hibernate. You can verify that by right-clicking on the menu when you resume and seeing if "Networking Enabled" is unchecked.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 19:50 UTC (Thu) by tetromino (subscriber, #33846) [Link]
That is a known bug in vanilla networkmanager-0.7.1. You need some patches that a number of distros have helpfully backported from networkmanager trunk.
See https://bugs.gentoo.org/show_bug.cgi?id=262112 or https://bugzilla.redhat.com/show_bug.cgi?id=441070 for details.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 26, 2009 0:09 UTC (Fri) by rberger (guest, #52829) [Link]
Thanks both for your replies.
As to "how long", from half an hour to overnight. In fact, I rarely shut my desktop totally down but rather just suspend to RAM.
And yes, I thought it was kind of a bug and vaguely recall reading some post about NM "giving up too soon" trying to get the interface up upon resume, which I'd expect to get fixed one time or the other. In fact, my Debian Lenny version is fairly old
Still, again, thanks for the clarification.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 19:13 UTC (Thu) by dcbw (guest, #50562) [Link]
Of course it's one-sided, I'm attempting to refute some completely misguided claims that the slide deck makes about NetworkMananger.
The PPT is very recent as its from 2009, which means it can only be 6 months old max.
AFAIK, connman doesn't have any VPN support at all, either. The slide deck lists that as "future work".
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 17:55 UTC (Thu) by yokem_55 (subscriber, #10498) [Link]
My primary complaint about NetworkManager is that unless you are using nm-applet, which pulls in half of gnome (why exactly can't nm-applet be gtk only?) your mileage will vary greatly in making NM work. The old knetworkmanager doesn't work with NM .7, and the new plasma network-management applet is still quite buggy. And while primarily a distributor problem, there is a nearly indecipherable maze of dbus permissions that have to be properly set in order to actually set up connections. In sum, I've dumped NM in favor of wicd. While it certainly has much fewer features, it works well without a lot of headaches.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 18:40 UTC (Thu) by kmike (guest, #5260) [Link]
I wholeheartedly agree. wicd "just works" on a Ubuntu Remix-powered netbook compared to NetworkManager, despite (or thanks to) having fewer features.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 19:12 UTC (Thu) by dcbw (guest, #50562) [Link]
Because it uses gnome-keyring for secure password storage (do you really want your VPN passwords or WPA passphrases in cleartext in your homedir?), GConf for storing your wireless settings, and PolicyKit to ensure that unauthorized users can't muck around with your network settings.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 21:19 UTC (Thu) by russell (subscriber, #10458) [Link]
To me these are not good. This makes it very difficult to find out what's happening behind the scenes. I don't think it's just me, I've talked to other people who have found it difficult to work with as well.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 22:07 UTC (Thu) by elanthis (guest, #6227) [Link]
Honestly, I don't care about the passwords being in plaintext. If someone steals my laptop, they're going to get the info anyway. I don't password-protect gnome-keyring either, because that's a pain in the ass, and the few passwords stored in there don't matter a whit compared to all my files (and the actual hardware itself, which isn't cheap).
Passwords for WPA aren't to make my network secure, they're just there to stop random Joe Blow from using my connection without asking me first.
VPNs (and corporate wirless, I suppose) are a slightly different story (depends on the VPN network architecture, honestly), but then I've never been one to believe that I should pay a price for features I'm not using. I don't have a VPN connection to worry about, so I shouldn't be forced to use a bunch of dependencies and jump through extra hoops meant to keep VPN passwords secure.
(Note: I have zero problem with nm-applet depending on GNOME stuff since I'm a GNOME user anyway. But understanding where other people are coming from is a good thing to do.)
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 26, 2009 23:02 UTC (Fri) by jgg (guest, #55211) [Link]
For VPN passwords I actually don't wan them *STORED AT ALL* and I really loath the default network manager behavior of constantly prompting me with all defaults set to yes to do exactly that. So annoying.
Especially for enterprise users! There is ONLY ONE PASSWORD. Samaba hashes and caches it for offline use. I provide it at GDM login time, it is kept in RAM by Samaba. All this stuff NM does for passwords for enterprise features like VPN and EAP is just totally wrong headed. Get the password from GDM or Samba, transparently pass it on.
gnome-keyring is a hack.
Sigh, it is so depressing that simple enterprise things like this in Linux are still missing. Even on the latest Ubuntu I cannot print over SMB using my Kerberos ticket. I can do everything else, but not print. Still. Lame.
Yes please Posted Jun 28, 2009 21:36 UTC (Sun) by job (guest, #670) [Link]
I always found that behaviour a bit wierd, at least for WLAN passwords. Most people probably wants to keep them in plain text, and the rest can enable the feature if they need it. If you don't store them on disk, I bet you store them in paper, because you need them as soon as you use set up a new device (and everything from mobile phones to mp3 players needs WLAN access today).
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 21:06 UTC (Thu) by drag (subscriber, #31333) [Link]
> My primary complaint about NetworkManager is that unless you are using nm-applet,
Ya. I want a nice command line client. I don't like having to to rely on GUI stuff all the time, especially when X falls over for some reason. (I suppose I should work on one, maybe a fun project)
The other thing I really dislike about Network-Manager is that if I fool around with my wifi stuff and NM drops control of the interface I can't figure out how to make it take control of the wifi device again. It's maddenning.
But I still love it. I can't use Linux on a mobile device anymore without it. Through my day I use no less then 4 seperate networks on my laptop. I randomly encounter about a dozen encrypted networks over a month. I travel and connect to dozens of unique networks every few months. I rely on quick and efficient means to connect to the internet whenever and however possible.
When I am in a meeting or I have somebody breathing down my neck or need to look up something I'll pull my laptop out of the bag, open it up, it 'unsuspends' and the average time it takes to find some sort of internet access, if avialable at all, is about 5 minutes.
I love that it uses Policykit. No sudo access on my laptop.
I have setup laptops for other people to use and they need to connect to other networks... No 'sudo' at all. No GTK-sudo, or GTK-su or any of that horrific nonsense. No root passwords, no setuid root programs, no nothing. I don't give them root passwords at all or anything like that. Just a user account and nm-applet is all they need. Poof-Done.
Same thing with VPNs. Sure it sucks that it only supports one VPN at a time, but whatever. It works and it requires no root access. Love it.
And the same thing with GSM modems. I connect phones, it just works. I am looking forward to bluetooth support. That is the one huge thing that OS X holds over Linux.
------------------
The one thing that drove me to use Network-Manager is that I find the idea that I need to have root rights to be able to connect to various networks on a mobile device is just abhorrent.
I previously used Debian's ifup and ifdown stuff with the wpa_supplication integration into /etc/network/interfaces and all that happy stuff. For what I needed that was really the best solution. And as far as solutions go it _is_ the best distro-specific solution I've ever run across.
I still absolutely depend on it for when I need to setup routers or linux-based access points and stuff like that. It's just fantastic... but on a laptop or netbook not-so-much.
Whenever I connected to a new network I always felt the fool when I had to far around with editing files to record the new passwords and I was angry that I had to keep using 'sudo' or su or whatever. It's just stupid and a security problem.
It's like having to go in and edit Xorg.conf when connecting a new monitor or configure a wacom tablet. It's just asinine to have to go through things like that.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 22:57 UTC (Thu) by leoc (subscriber, #39773) [Link] In the previous thread, cnetworkmanager was mentioned as a command line interface for NM.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 26, 2009 14:47 UTC (Fri) by drag (subscriber, #31333) [Link]
I know. I've tried it in the past and it's not nice.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 18:04 UTC (Thu) by marcH (subscriber, #57642) [Link]
> Dan Williams discusses the advantages of NetworkManager over ofono and ConnMan on his blog.
Well, not really. He is rather refuting some NetworkManager bashing.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 26, 2009 2:29 UTC (Fri) by russell (subscriber, #10458) [Link]
Some of Dan's claimed features such as "integration" have never worked on fedora. I keep trying with each release but...
https://bugzilla.redhat.com/show_bug.cgi?id=491449
without this, a system wide connection seems impossible ( which is ridiculous ). How is ntpd, sshd, etc suppose work without anyone logged in?
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 26, 2009 8:13 UTC (Fri) by cyperpunks (subscriber, #39406) [Link]
Even better if you need net to login (e.g. NIS or LDAP auth)...
How hard can it be to understand that if you have put a network cable into the machine you want to have network connection?
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jul 6, 2009 13:55 UTC (Mon) by stevem (subscriber, #1512) [Link]
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532670 for an example of why we've had to remove NM from most of the desktops at my company.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 26, 2009 11:01 UTC (Fri) by dcbw (guest, #50562) [Link]
People still wanted a way to make NetworkManager ignore an interface. That's what happened in that bug. NM_CONTROLLED=no was set in the ifcfg file, and thus NM ignores the interface just like the user requested.
Were NM_CONTROLLED not present or "yes", NM would be able to control that interface and bring it up before login.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 20:54 UTC (Thu) by chris144 (guest, #30028) [Link]
One of the big disadvantages about NM is that it does not allow any other entity to set up a connection and then hand over that connection to NM or at least make NM know about it. If NM wants to be the all "Ruling Ring" it needs to open up and provide at least a minimal interface to integrate with other apps that set up custom connections. Form my point of view it is ok for NM to rule them all, but please, then a connection handover dbus interface or "know about custom connection" interface is overdue.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 26, 2009 11:19 UTC (Fri) by dcbw (guest, #50562) [Link]
There's a few reasons why this is not really useful.
First, it makes most of the flexibility of the NM D-Bus interface completely useless. NM provides a *lot* of information about the interface over D-Bus: DHCP options, complete IP config details including multiple IP addresses, routes, DNS information, etc. The custom connection would have to push all that information to NetworkManager *and* push updates periodically if that information changed.
Second, it renders the configuration system useless, because the custom connection wouldn't be using the same configuration system as NetworkManager, and users would have to configure connections in multiple places and store configuration in multiple places.
Third, because of #2, applications and clients would have to write *multiple* methods of figuring out all the stuff they can just ask NetworkManager for right now (ie, both #1 and #2) because NetworkManager would not have a full picture of the networking of the machine, precisely because some other program was actually managing a connection.
Neither NM nor ConnMan pretend to be connection "arbitrators": they are both connection _managers_. They actively control the connections on the machine, they don't just act as a traffic cop between other connection managers. There are some good reasons for that; consistency, predictability, ease of configuration, etc. Turning either one into an arbitrator basically destroys most of the reasons a connection manager is useful.
If you're talking about more of a plugin-type method of NM deciding to activate a connection, and sending connection configuration to a loaded plugin that then handles the low-level configuration of the interface, and returns information to NetworkManager that NM can use to set up the higher level configuration, then great. That's pretty easy to do, and that's what we're *already* doing with ModemManager and wpa_supplicant, and in the future WiMAX. I have no problem with that, because it preserves the consistency, predictability of policy, and ease of configuration.
People always want to take the easy way out, the quickest path to a destination or solution to a problem. That's not always the *right* path. In the end, it's better to fix the problem in the correct manner that's more usable (by adding support for Bluetooth directly) than hacking around the problem in a way that limits the knowledge of the entire system (ie. instead of say tricking NM into seeing the device as a plain 56k dialup modem or ethernet device).
I'm interested in what connection method you're trying to use that isn't working for you, so that we can support it correctly. The only thing stopping lots of great support for more things (ISDN, 56k dialup, IPSec) is lack of people to add that support.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 29, 2009 11:48 UTC (Mon) by jlokier (guest, #52227) [Link] Since you ask, these things don't work with NM in my experience so far:
If there's a simple plugin interface where all these things can be scripted to work properly, or a simple configuration file like most daemons, well "man" didn't show anything useful. Make it more accessible in a unixy way - with a proper man page, proper options and a proper config file, and I think that will clear up most user's concerns.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 29, 2009 22:02 UTC (Mon) by Frej (subscriber, #4165) [Link]
> 1. Simple configurations which are already in /etc/network/interfaces. Don't ask me why, I've been told they should work with the appropriate NM setting. Why do I have *two* identical "wired eth0" entries in nm-applet, but only one works. I don't know.
I don't think NM understands /etc/network/interfaces other than if it should ignore the interface or not. The double wired interfaces is probably a bug maybe in nm-applet or network driver (wired usually works though).
> 2. Interfaces with bridges, so that local KVMs can be used. These need the DHCP client and/or static IP settings to be done on the bridge interface, but the rest of management - wireless keys or wired signal detection - to use the real interface. It's a real pain to have to kill NM and manually set up a wireless network when I want to use KVM, particularly as it means wireless config is duplicated inside and outside NM, and the nice NM roaming isn't available.
I can highly recommend virt-manager - i've never needed to care about kvm and network setup. And never needed to disable nm.
> 3. OpenVPN with additional options not listed in the GUI.
That should probably be patchable ;)
> 4. 3g bluetooth connections - I have a script which kills NM to use 3g, and restart NM when I've finished using 3g.
> 5. Command line use, for when you log in but not with a GUI, or X is broken. Sure, that's unusual, but when it happens it's really unhelpful that your wireless network configuration is stored only in a place where you can't use or even read it.
Everybody agrees that cli interface would be nice. But your info is in /etc/NetworkManager (if it set as a system setting, otherwise the somewhat painfull gconftool-2 can help)
> 6. Automatic NM-managed wireless connection when not logged in. Others have mentioned uses.
I've Never tried that? Should work with when it's a system setting - or is the password not saved in system settings? :(
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 29, 2009 22:34 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
one of the claims for NM is that it works with the distro config files instead of needing to do it's own thing.
this doesn't match my experiance either.
NM works for most people most of the time, and that's about all that I would expect from any tool like this (there are just _too_ many ways for networking to be configured). my problem with NM is that it has no allowance for the cases where it doesn't work, you have to uninstall it to be able to do anything else.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Aug 2, 2009 1:11 UTC (Sun) by bfields (subscriber, #19510) [Link] "I can highly recommend virt-manager - i've never needed to care about kvm and network setup. And never needed to disable nm."Is your host doing NAT for the kvm guests? I find that works fine by default. But last time I needed to put the kvm guests on the real network (using bridging, as in the parent comment), I found libvirt and nm weren't enough--I needed to turn off nm and do all the setup manually. (But it may be that I missed some libvirt configuration that could have helped.)
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 21:00 UTC (Thu) by lkundrak (subscriber, #43452) [Link]
NM definitely improved a lot with 0.7 version and actually became really
useful. The human interface could still be improved a lot to avoid surprises ("I created a wireless network; now how do I disable it?", "I'm connected to two networks via two ethernet devices, how do I disconnect one?", "Ouch, there is a connection editor and I actually need it to do this?"), and not supporting less usual scenarios such as multiple VPN connections is not an advantage either.
I like the idea that ConnMan is strengthening competition
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 21:01 UTC (Thu) by jimparis (subscriber, #38647) [Link]
If ConnMan is anything like the userspace bluez stuff, I'll be happy to stick with NetworkManager forever. To be fair, I can't tell if my problems with bluez are because of:
- my lack of experience in using it right - unsupported or uncommon devices or use cases - huge code and structural changes from 3.x to 4.x - distributions not packaging stuff right but I didn't see "bluez maintainer" in those slides as a selling point...
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 25, 2009 23:57 UTC (Thu) by ken (subscriber, #625) [Link]
Bluez is definitely one of the more annoying parts of linux. the ratio of time spent trying to get it to work and actually working is way tilted to the first. And most of the time it's a struggle to even get an idea on how it's supposed to work making it even harder to fix.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 26, 2009 15:03 UTC (Fri) by vudentz (guest, #57202) [Link]
That must be why Maemo, android and all Linux distro I care about uses BlueZ, while I can't say the same about NetworkManager. NetworkManager is cursed by using dbus-glib and gobject, but it is also bad designed in many ways:
- It force the ui to hold a well know name on _SYSTEM_ bus, so that mean it not only does _not_ support multiple instances of the applet but also you cannot decentralized the control over different processes.
- libnm-glib defeat the purpose of the bindings and create yet another API, but not only that it also makes the same mistake of dbus-glib naming where -glib is used instead of -gobject.
- The applet caries so much of the logic that I bet writing one takes a _lot_ more time (even using libnm-glib) than writing one for connman.
- dbus-glib and its static spec written in .xml is evil, one cannot have objects with different set of interfaces because the .xml is static. This makes introspection aware bindings like python useless and create workarounds like GetInterfaces used by telepathy which return the _real_ introspection data.
- gobject is useless for daemons, it take twice as much code to write the very same thing only using glib (one can find a real example of it comparing obex-data-server and obexd), debugging is a lot more painful, it consumes more memory and it is much slower.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 26, 2009 16:26 UTC (Fri) by jimparis (subscriber, #38647) [Link]
> That must be why Maemo, android and all Linux distro I care about uses
> BlueZ, while I can't say the same about NetworkManager.
A strong reason they use BlueZ because there are no alternatives. In some cases (such as android) they have wrapped their own user interfaces and utilities around it, to make it actually usable.
> NetworkManager is cursed by using dbus-glib and gobject, but it is also
While I can't argue about the design (because I haven't studied the implementation), I also simply do not care, and that's my point. For this project, I'm just the target audience, not a developer. It doesn't matter to the typical user how NetworkManager is implemented -- it matters that it works. And for me, and many other users, it works very well.
Bluez, on the other hand, might be implemented very well, but the user experience is a complete mess. And so when I hear that the Bluez guys are making a NetworkManager replacement, I'm extremely skeptical that it's something I'd ever want to use.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 26, 2009 18:13 UTC (Fri) by vudentz (guest, #57202) [Link]
> Bluez, on the other hand, might be implemented very well, but the user
> experience is a complete mess. And so when I hear that the Bluez guys are > making a NetworkManager replacement, I'm extremely skeptical that it's > something I'd ever want to use.
Are you sure you know what you are talking about? BlueZ is not about user experience, there is no UI component on it. And we pass qualification tests (http://www.bluez.org/qualification/) that is what matter for a bluetooth stack. You can blame gnome-bluetooth and kbluetooth4 for that but definably not BlueZ.
Now I know why people care so much about NetworkManager, it is just because the ui, well I wouldn't be surprised if someone just use the same ui as frontend for both connman and NetworkManager, so I don't think this is a big deal and yes it is all about implementation detail both _do_ work fine.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 27, 2009 1:29 UTC (Sat) by dcbw (guest, #50562) [Link]
>- It force the ui to hold a well know name on _SYSTEM_ bus, so that mean
> it not only does _not_ support multiple instances of the applet but also > you cannot decentralized the control over different processes.
Root daemons cannot access the session bus, nor should they allowed to, which is why D-Bus does not allow it. So we are left with either private connections, or the system bus. Private connections would work fine too, and NetworkManager may well move over to use them; it is simply an implementation detail.
However, there still should be only *one* authorized user settings service, since (except for specialized multi-seat configurations) there should only ever be one user controlling the network at a time. NetworkManager could do the access control inside itself to only allow the current session's (determined by ConsoleKit) applet control of the network, and in fact that's how NetworkManager will work, but I argue there is nothing fundamentally broken about the current design. There is no reason to run multiple user settings services on the bus.
I've already started fixing the applet for multi-login. But in any case, I'm curious what exactly you're having problems with, if it's something other than fast-user-switching (which is already known).
> - libnm-glib defeat the purpose of the bindings and create yet another
The naming point is fair. But what's the problem with the libnm-glib API? Please provide some concrete points. If you want to bind NetworkManager in say Python, you should be creating pure Python+D-Bus bindings. You should not be using libnm-glib from anything other than a glib-based C application. For that, libnm-glib saves a *TON* of code in the client app. It's a pretty big win.
> - The applet caries so much of the logic that I bet writing one takes a
This is exceptionally false. Please elaborate. There are two components to the applet: (a) the user-settings service (which, if you are writing an applet, you do *not* have to implement, you can depend on user-settings yourself), and (b) the UI itself.
(a) is quite simple in Python, but then most everything is. The largest effort in (a) is writing the code to marshal your custom data format (in the applet's case this is GConf) into the NMConnection structure, which is purely a dict of dicts. This should not be difficult unless the developer does not understand D-Bus at all.
(b) is also fairly simple. You have Connections, as provided either by the system settings service or the user settings service. NetworkManager gives you devices. You match up the connections with devices. If it's a wifi device, obviously a wifi connection can be used with that device. If it's a GSM 3G device, obviously a GSM 3G connection may be used with it. I don't really understand your problem here, I'd love to know what the issue is.
Can it be easier? Yes, somewhat. But fundamentally, networking is hard, and to make it easy for the user, the developers need to do a bit more work. Please read my comment above to wstephenson about SSID coalescing for example. You *cannot* simplify that beyond grouping SSIDs by (SSID, band, security). NetworkManager chooses to let the UI do the coalescing, so as not to apply a specific policy, based on our experiences with NM 0.6 where we did coaelesce SSIDs which, it turns out, you simply cannot do.
>- dbus-glib and its static spec written in .xml is evil, one cannot have
The correct Python binding of NetworkManager should be a direct binding to the NetworkManager D-BUs interface. You should not be trying to bind another binding (ie, libnm-glib). That's just pointless.
I don't understand your comment about "cannot have objects with a different set of interfaces" here; I know of some problems with dbus-glib and interfaces, but I'm not quite sure what you mean. But does that mean dbus-glib cannot be fixed? Maybe not. But perhaps eggdbus is a better future option or something.
> - gobject is useless for daemons, it take twice as much code to write
I very much disagree. It does *not* take twice as much code to write, and it gives quite a lot of flexibility. We'll just have to disagree here. I've written a ton of GObject code, lots of it in NetworkManager, and I have to say, GObject has made my life a *lot* easier, and I do not believe I could have developed NetworkManager as quickly or as easily writing my own re-implementation of GObject and GInterface. I (and quite a lot of other people) do not have a problem debugging GObject.
I also do not believe that the memory usage or performance is significantly higher *for this use-case*. You can obviously find some synthetic tests that will prove that GObject is slower for this Phoronix benchmark or that Phoronix benchmark, but I do not believe that they are relevant for the real world or for NetworkManager.
Platforms like Maemo, the Palm Pre, and (I think) the Kindle are already using and shipping GObject and GObject-based libraries. Thus, there are already real-world cases where *embedded* device makers decided that the tradeoff of shipping GObject was worth the benefits. So I simply don't understand the drive to toss GObject out.
No, the network should not be limited to one user Posted Jun 27, 2009 2:46 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
you may need to have a user enter credentials to login to some networks, but you absolutly should NOT take the position that only one user should control the network (unless that user is root, which you also disagree with)
while multiple people on one machine is not as common as it used to be, something as fundamental as network access should not be limited to a single user, or a single users session.
with this as your attitude, I hope that alternate tools become much more common and network manager can go off and play in your small subset of the linux ecology
No, the network should not be limited to one user Posted Jul 6, 2009 14:50 UTC (Mon) by stevem (subscriber, #1512) [Link]
+1
Networking is a per-system feature, not a per-user feature. By all means have nice pretty tools for users to configure the network, but needing a user session to make things work at all is just daft.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 28, 2009 6:20 UTC (Sun) by vudentz (guest, #57202) [Link]
Let me reply short, something you really should improve otherwise you sound like a politician.
1. Well know name holding by a user application on SYSTEM bus is _fundamentally_ ..., well I will not going to lose my time time here you can check connman code and you will find it doesn't require such thing.
"There is no reason to run multiple user settings services on the bus." Then why do you need user setting in the first?
2. For gnome applet perhaps, but I see it from another perspective: you got libnm-glib because dbus-glib is not a good binding and also because it seems you didn't spend a lot of time making the spec in shape. The spec uses very complex signatures and enums (have you learn this from telepathy?).
3, 4 and 5. All this arguments you posted may be valid for gnome desktop, for the rest, not even close. If you don't get it, then I can't help you, but I guess people are starting to figure out this is not a good idea (pushing gnome/gobject software to the daemon realm), devicekit was a gnome thing and Im glad its being dropped in favor of direct udev (gudev).
People that do care about _LINUX_ desktop (like enlightenment) will probably use connman from now on and I hope KDE will follow.
I don't want to ever see this gobject messages on my syslog again.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 28, 2009 11:41 UTC (Sun) by nix (subscriber, #2304) [Link]
Uh, glib isn't terribly heavyweight, you know. syslog-ng moved to using
glib some time ago (from its previous weird homerolled object system), and y'know how many problems that caused that critical system daemon?
None, that's how many.
I'd understand your complaints if it was *gtk* being pulled in, but glib?
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jul 2, 2009 16:43 UTC (Thu) by blitzkrieg3 (subscriber, #57873) [Link]
Thanks for your insight Dan,
>Root daemons cannot access the session bus, nor should they allowed to,
The fundamental problem I have with this is that only one program can access the network state at _any_ given time. There is a supposed cli implementation out there, but I wonder how it would work with nm-applet in my gnome desktop. I prefer the keyboard, but would I be able to type nmcli join myhomenetwork?
Maybe we can have a multiplexer daemon that can accept commands from anywhere and send them to the nm daemon via the one true nm dbus connection. It would have to use some sort of system bus for communication and a set of commands to change networks and such... oh wait...
;)
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 29, 2009 0:52 UTC (Mon) by bojan (subscriber, #14302) [Link]
Spent better part of the weekend trying to get NM to work with my simple LAN and WPA2-PSK WLAN setup (it worked by hand from the start, BTW). After reading idiotic amount of pages pointed to by Google, I could not get NM to actually work on Fedora 11. Not to mention all the bugs in the UI, where my one connection would triplicate for reasons completely unknown to me.
End result? I now have a 32 line script that switches automatically between my LAN and WLAN connections. Reliably. Every time. No exceptions.
Oh, and "yum -y remove NetworkManager" is your friend ;-)
PS. Red Hat Bugzilla is littered with bugs related to all of these problems. I didn't find the need to open more.
PPS. Sure, I'll give NM a try in the future. For now, I found it completely useless.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 30, 2009 3:17 UTC (Tue) by bojan (subscriber, #14302) [Link] I now have a 32 line script that switches automatically between my LAN and WLAN connections. And here is the same thing in C (lower memory/CPU footprint than script):
#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>
#include <string.h>
#include <unistd.h>
#include <limits.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <signal.h>
#include <wait.h>
#define LF "/var/lock/wlan-control"
static void cleanup(){
unlink(LF);
}
static int run(const char *path,...){
pid_t pid;
int status,nargs=0;
const char **args,**p;
va_list ap;
va_start(ap,path); for(;va_arg(ap,const char*);nargs++); va_end(ap);
args=calloc(nargs+2,sizeof(*args));
*args=path;
va_start(ap,path); for(p=args+1;(*p=va_arg(ap,const char*));p++); va_end(ap);
if(!(pid=fork())){
if(execv(path,(char *const *)args)==-1)
exit(1);
} else{
waitpid(pid,&status,0);
}
free(args);
return status;
}
int main(int argc,char **argv){
int fd;
char buf,old,new,*eth,*wln,lan[PATH_MAX],air[PATH_MAX];
if(argc<3)
return 1;
if((fd=open(LF,O_CREAT|O_EXCL|O_WRONLY,0))==-1)
return 1;
close(fd);
atexit(cleanup);
signal(SIGINT,exit);
signal(SIGTERM,exit);
eth=*(argv+1);
wln=*(argv+2);
snprintf(lan,sizeof(lan),"/sys/class/net/%s/carrier",eth);
snprintf(air,sizeof(air),"/sys/class/net/%s/carrier",wln);
if((fd=open(lan,O_RDONLY))==-1){
run("/sbin/ip","link","set","dev",eth,"up",NULL);
if((fd=open(lan,O_RDONLY))==-1)
return 1;
}
if(read(fd,&old,sizeof(old))!=sizeof(old)){
run("/sbin/ip","link","set","dev",eth,"up",NULL);
if(read(fd,&old,sizeof(old))!=sizeof(old)){
close(fd);
return 1;
}
}
close(fd);
while(1){
new=old;
if((fd=open(lan,O_RDONLY))==-1){
run("/sbin/ip","link","set","dev",eth,"up",NULL);
if((fd=open(lan,O_RDONLY))==-1)
goto sleep;
}
if(read(fd,&new,sizeof(new))!=sizeof(new)){
run("/sbin/ip","link","set","dev",eth,"up",NULL);
if(read(fd,&new,sizeof(new))!=sizeof(new)){
close(fd);
goto sleep;
}
}
close(fd);
if(new!=old){
switch(new){
case '1':
run("/sbin/ifdown",wln,NULL);
run("/sbin/service","wpa_supplicant","stop",NULL);
run("/sbin/ifdown",eth,NULL);
run("/sbin/ifup",eth,NULL);
break;
case '0':
run("/sbin/ifdown",eth,NULL);
run("/sbin/ifdown",wln,NULL);
run("/sbin/service","wpa_supplicant","restart",NULL);
sleep(10);
run("/sbin/ifup",wln,NULL);
if((fd=open(air,O_RDONLY))==-1){
run("/sbin/ifdown",wln,NULL);
run("/sbin/service","wpa_supplicant","stop",NULL);
goto out;
}
if(read(fd,&buf,sizeof(buf))!=sizeof(buf) || buf=='0'){
close(fd);
run("/sbin/ifdown",wln,NULL);
run("/sbin/service","wpa_supplicant","stop",NULL);
goto out;
}
close(fd);
break;
default:
break;
}
out:
old=new;
}
sleep:
sleep(10);
}
return 0;
}
Not really thoroughly debugged, but it does work on two of my notebooks just fine.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jul 4, 2009 5:55 UTC (Sat) by jmm82 (guest, #59425) [Link]
You created a throw away program that fits the needs of ONE Linux user, targeted at ONE specific piece of hardware. Now take that program you wrote and make it fulfill the needs of every single Linux user, with every possible piece of hardware, and wanting to do everything possible inside the Linux kernel with their network, using one application and then maybe you have done something noteworthy.
Currently, this application does not exist and it probably never completely will.
My point being NM may not work right out of the box on every computer, but it works on most computers rather well, which is somewhat of an accomplishment in itself. Dan William's does an outstanding job of fixing bugs that are reported to him and if you joined the network manager mailing list and took the time to post your debug logs, I am sure you would find that either a. your bug has already been fixed upstream or b. someone on the list would help to fix it.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 29, 2009 9:10 UTC (Mon) by spaetz (subscriber, #32870) [Link]
Hi Dan,
having read all those "it doesn't work here" posts, I just felt the urge to express my thanks:
It works wonderful and reliably here. WLAN, Ethernet, Suspend/Wakeup, unencrypted and WPA, VPN integration... For my part, I am quite happy with it.
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 29, 2009 22:13 UTC (Mon) by Frej (subscriber, #4165) [Link]
Yeah i guess handling hackers connection to the internet is bound to catch flak. Even more important than browser UI.
|
|||||||||||||