NetworkManager and ConnMan (Dan Williams' 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).
Posted Jun 25, 2009 17:43 UTC (Thu)
by s0f4r (guest, #52284)
[Link] (9 responses)
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.
Posted Jun 25, 2009 17:49 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
Posted Jun 26, 2009 21:29 UTC (Fri)
by s0f4r (guest, #52284)
[Link]
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.
Posted Jun 25, 2009 17:53 UTC (Thu)
by bluss (guest, #47454)
[Link] (1 responses)
Posted Jun 25, 2009 21:22 UTC (Thu)
by nhippi (subscriber, #34640)
[Link]
Posted Jun 25, 2009 17:54 UTC (Thu)
by rberger (guest, #52829)
[Link] (3 responses)
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.
Posted Jun 25, 2009 19:16 UTC (Thu)
by dcbw (guest, #50562)
[Link]
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.
Posted Jun 25, 2009 19:50 UTC (Thu)
by tetromino (guest, #33846)
[Link] (1 responses)
See https://bugs.gentoo.org/show_bug.cgi?id=262112 or https://bugzilla.redhat.com/show_bug.cgi?id=441070 for details.
Posted Jun 26, 2009 0:09 UTC (Fri)
by rberger (guest, #52829)
[Link]
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.
Posted Jun 25, 2009 19:13 UTC (Thu)
by dcbw (guest, #50562)
[Link]
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".
Posted Jun 25, 2009 17:55 UTC (Thu)
by yokem_55 (subscriber, #10498)
[Link] (9 responses)
Posted Jun 25, 2009 18:40 UTC (Thu)
by kmike (guest, #5260)
[Link]
Posted Jun 25, 2009 19:12 UTC (Thu)
by dcbw (guest, #50562)
[Link] (4 responses)
Posted Jun 25, 2009 21:19 UTC (Thu)
by russell (guest, #10458)
[Link]
Posted Jun 25, 2009 22:07 UTC (Thu)
by elanthis (guest, #6227)
[Link]
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.)
Posted Jun 26, 2009 23:02 UTC (Fri)
by jgg (subscriber, #55211)
[Link]
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.
Posted Jun 28, 2009 21:36 UTC (Sun)
by job (guest, #670)
[Link]
Posted Jun 25, 2009 21:06 UTC (Thu)
by drag (guest, #31333)
[Link] (2 responses)
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.
Posted Jun 25, 2009 22:57 UTC (Thu)
by leoc (guest, #39773)
[Link] (1 responses)
Posted Jun 26, 2009 14:47 UTC (Fri)
by drag (guest, #31333)
[Link]
Posted Jun 25, 2009 18:04 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (4 responses)
Well, not really. He is rather refuting some NetworkManager bashing.
Posted Jun 26, 2009 2:29 UTC (Fri)
by russell (guest, #10458)
[Link] (3 responses)
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?
Posted Jun 26, 2009 8:13 UTC (Fri)
by cyperpunks (subscriber, #39406)
[Link] (1 responses)
How hard can it be to understand that if you have put a network cable into the machine you want to have network connection?
Posted Jul 6, 2009 13:55 UTC (Mon)
by stevem (subscriber, #1512)
[Link]
Posted Jun 26, 2009 11:01 UTC (Fri)
by dcbw (guest, #50562)
[Link]
Were NM_CONTROLLED not present or "yes", NM would be able to control that interface and bring it up before login.
Posted Jun 25, 2009 20:54 UTC (Thu)
by chris144 (guest, #30028)
[Link] (5 responses)
Posted Jun 26, 2009 11:19 UTC (Fri)
by dcbw (guest, #50562)
[Link] (4 responses)
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.
Posted Jun 29, 2009 11:48 UTC (Mon)
by jlokier (guest, #52227)
[Link] (3 responses)
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.
Posted Jun 29, 2009 22:02 UTC (Mon)
by Frej (guest, #4165)
[Link] (2 responses)
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? :(
Posted Jun 29, 2009 22:34 UTC (Mon)
by dlang (guest, #313)
[Link]
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.
Posted Aug 2, 2009 1:11 UTC (Sun)
by bfields (subscriber, #19510)
[Link]
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.)
Posted Jun 25, 2009 21:00 UTC (Thu)
by lkundrak (subscriber, #43452)
[Link]
I like the idea that ConnMan is strengthening competition
Posted Jun 25, 2009 21:01 UTC (Thu)
by jimparis (guest, #38647)
[Link] (10 responses)
Posted Jun 25, 2009 23:57 UTC (Thu)
by ken (subscriber, #625)
[Link]
Posted Jun 26, 2009 15:03 UTC (Fri)
by vudentz (guest, #57202)
[Link] (8 responses)
- 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.
Posted Jun 26, 2009 16:26 UTC (Fri)
by jimparis (guest, #38647)
[Link] (1 responses)
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.
Posted Jun 26, 2009 18:13 UTC (Fri)
by vudentz (guest, #57202)
[Link]
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.
Posted Jun 27, 2009 1:29 UTC (Sat)
by dcbw (guest, #50562)
[Link] (5 responses)
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.
Posted Jun 27, 2009 2:46 UTC (Sat)
by dlang (guest, #313)
[Link] (1 responses)
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
Posted Jul 6, 2009 14:50 UTC (Mon)
by stevem (subscriber, #1512)
[Link]
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.
Posted Jun 28, 2009 6:20 UTC (Sun)
by vudentz (guest, #57202)
[Link] (1 responses)
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.
Posted Jun 28, 2009 11:41 UTC (Sun)
by nix (subscriber, #2304)
[Link]
None, that's how many.
I'd understand your complaints if it was *gtk* being pulled in, but glib?
Posted Jul 2, 2009 16:43 UTC (Thu)
by blitzkrieg3 (guest, #57873)
[Link]
>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...
;)
Posted Jun 29, 2009 0:52 UTC (Mon)
by bojan (subscriber, #14302)
[Link] (2 responses)
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.
Posted Jun 30, 2009 3:17 UTC (Tue)
by bojan (subscriber, #14302)
[Link] (1 responses)
And here is the same thing in C (lower memory/CPU footprint than script): Not really thoroughly debugged, but it does work on two of my notebooks just fine.
Posted Jul 4, 2009 5:55 UTC (Sat)
by jmm82 (guest, #59425)
[Link]
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.
Posted Jun 29, 2009 9:10 UTC (Mon)
by spaetz (guest, #32870)
[Link] (1 responses)
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.
Posted Jun 29, 2009 22:13 UTC (Mon)
by Frej (guest, #4165)
[Link]
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
ii network-manager 0.6.6-3
but hey, before patching up packages myself as bugs pop up (and taking the risk of maybe running into new troubles with more up to date versions) I just shut them off where I realize I don't really need them.
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
Yes please
NetworkManager and ConnMan (Dan Williams' Blog)
In the previous thread, cnetworkmanager was mentioned as a command line interface for NM.
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
Missing feature, should work soonish? At least it's touted as a upcoming feature - but that's probably too late for you :-).
NetworkManager and ConnMan (Dan Williams' Blog)
"I can highly recommend virt-manager - i've never needed to care about kvm and network setup. And never needed to disable nm."
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
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.
here and is actually going to help NM improve.
NetworkManager and ConnMan (Dan Williams' Blog)
- 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)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
> BlueZ, while I can't say the same about NetworkManager.
> bad designed in many ways:
NetworkManager and ConnMan (Dan Williams' Blog)
> 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)
> it not only does _not_ support multiple instances of the applet but also
> you cannot decentralized the control over different processes.
> API, but not only that it also makes the same mistake of dbus-glib
> naming where -glib is used instead of -gobject.
> _lot_ more time (even using libnm-glib) than writing one for connman.
> 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.
> 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.
No, the network should not be limited to one user
No, the network should not be limited to one user
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
glib some time ago (from its previous weird homerolled object system), and
y'know how many problems that caused that critical system daemon?
Even if you're not using a single glib-using app, the memory hit is at
most a few dozen pages of memory, in *total*, across every single
glib-using app. Are you so memory-starved that a few dozen pages is even
detectable?
NetworkManager and ConnMan (Dan Williams' Blog)
>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.
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
I now have a 32 line script that switches automatically between my LAN and WLAN connections.
#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;
}
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)
NetworkManager and ConnMan (Dan Williams' Blog)