| |||||||||||||
|
| |||||||||||||
NetworkManager and ConnMan (Dan Williams' Blog)NetworkManager and ConnMan (Dan Williams' Blog)Posted Jun 26, 2009 11:19 UTC (Fri) by dcbw (guest, #50562)In reply to: NetworkManager and ConnMan (Dan Williams' Blog) by chris144 Parent article: NetworkManager and ConnMan (Dan Williams' Blog)
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.
(Log in to post comments)
NetworkManager and ConnMan (Dan Williams' Blog) Posted Jun 29, 2009 11:48 UTC (Mon) by jlokier (subscriber, #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.)
|
|
||||||||||||