So I use sys-apps/biosdevname to name my interfaces (which turns them into p34p1 and p37p1). Networkmanager handles this fine until the moment I try to change anything in nm-connection-editor. Way to reproduce: $ nmcli con NAMN UUID TYP TIMESTAMP-REAL Wired connection 2 69b11403-6d4a-4ae4-afbb-7fd1e8987db4 802-3-ethernet ons 16 maj 2012 22:28:24 Wired connection 1 c4e7b302-77cc-4ec5-b19c-b284e1ca17d4 802-3-ethernet ons 16 maj 2012 22:28:24 Start nm-connection-editor, select "Wired connection 2" and press edit. change anything and press save. You will notice that "Wired connection 2" in the list in nm-connection-editor disappears and instead two instances of eth0 appears. $ nmcli con NAMN UUID TYP TIMESTAMP-REAL eth0 a1a5b3d2-2e82-bbd6-f878-d26feacc2c7d 802-3-ethernet ons 16 maj 2012 22:28:12 Wired connection 1 c4e7b302-77cc-4ec5-b19c-b284e1ca17d4 802-3-ethernet ons 16 maj 2012 22:28:30 eth0 a1a5b3d2-2e82-bbd6-f878-d26feacc2c7d 802-3-ethernet ons 16 maj 2012 22:28:12 Then I restart NetworkManager and get $nmcli con NAME UUID TYPE TIMESTAMP-REAL Wired connection 1 6b6fd8e4-e122-4fad-8771-e1cc12e909ab 802-3-ethernet Wed May 16 22:31:03 2012 eth0 a1a5b3d2-2e82-bbd6-f878-d26feacc2c7d 802-3-ethernet Wed May 16 22:31:04 2012 $ nmcli dev DEVICE TYPE STATE p37p1 802-3-ethernet connected p34p1 802-3-ethernet connected And I want to add that the change I tried to do was to inactivate that device, which did not seem to happen. $ cat /etc/conf.d/net #Generated by NetworkManager ###### Global Configuration ###### ###### Connection Configuration ###### #---------------------------------- mac_eth0="00:24:8C:F8:25:68" enable_ipv6_eth0="true" auto_eth0="true" config_eth0=" dhcp dhcp6 " So something in the logic here seems wrong. Mostly because it seems like ifnet thinks all wired connections are "eth*", and that mac_eth0 identifies the device, which is wrong. mac_eth0 tries to modify the mac-address of interface, and makes this into a NOOP since eth0 does not exists at boot.
The plug-in doesn't have enough knowledge for the name of the network interface. For your case, you have to manually edit /etc/conf.d/net once. Please see if this helps: https://bugs.gentoo.org/show_bug.cgi?id=367517
(In reply to comment #1) > The plug-in doesn't have enough knowledge for the name of the network > interface. For your case, you have to manually edit /etc/conf.d/net once. This is perfectly true, as we don't (yet!) support device names in NetworkManager for ethernet devices. But when NetworkManager is running, it learns the device name at runtime. Modified name should normally not affect NetworkManager as it is using interface indexes most of the time. Bugs like this should be filed to the upstream bugzilla. There is nothing distribution specific in there.
(In reply to comment #2) > Bugs like this should be filed to the upstream bugzilla. There is nothing > distribution specific in there. Well partly it is. ifcfg-rh handles this by registering itself in dbus, and fetching the interface information that way. ifnet does not, so the question is which distributions that uses ifnet... But that plugin is maybe fully handled upstream?
This may so hurt with udev-197...
(In reply to comment #3) > (In reply to comment #2) > > Bugs like this should be filed to the upstream bugzilla. There is nothing > > distribution specific in there. > > Well partly it is. ifcfg-rh handles this by registering itself in dbus, and > fetching the interface information that way. First of all, ifcfg-rh is not Gentoo specific but Red Hat specific and therefore it doesn't affect whether a bug is more suitable for Gentoo or upstream. Next I would like to know what do you mean by ifcfg-rh getting this information by registering with dbus and what is your source of information. NetworkManager doesn't (yet) support interface names with the exception of bridging and bonding interfaces. None of the configuration plugins should do NetworkManager's core work and in fact I believe at least ifcfg-rh doesn't > ifnet does not, so the question is which distributions that uses ifnet... > But that plugin is maybe fully handled upstream? If “fully handled” is a synonym to “nobody really cares” then yes. Upstream doesn't care about distribution specific plugins unless someone keen on that distribution sends patches, at the least. A maintainer of the specific plugin would be better, of course.
(In reply to comment #5) > (In reply to comment #3) > > (In reply to comment #2) > > > Bugs like this should be filed to the upstream bugzilla. There is nothing > > > distribution specific in there. > > > > Well partly it is. ifcfg-rh handles this by registering itself in dbus, and > > fetching the interface information that way. > > First of all, ifcfg-rh is not Gentoo specific but Red Hat specific and > therefore it doesn't affect whether a bug is more suitable for Gentoo or > upstream. Next I would like to know what do you mean by ifcfg-rh getting > this information by registering with dbus and what is your source of > information. > I am fully aware of that ifcfg-rh is RedHat/Fedora specific, and has nothing to do with Gentoo, besides one thing: Working as a example of how to do things. And they do some thing the ifnet plugins is not capable of... Like: > NetworkManager doesn't (yet) support interface names with the exception of > bridging and bonding interfaces. None of the configuration plugins should do > NetworkManager's core work and in fact I believe at least ifcfg-rh doesn't http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/ifcfg-rh/plugin.c#n54 setting servicename for the dbus part of the ifcfg-rh plugin for usage by the ifcfg-rh plugin, probably to unlock http://projects.gnome.org/NetworkManager/developers/api/09/spec.html#org.freedesktop.NetworkManager.Device where I do not remeber exactly which (it was some time ago I did have time digging into this), but I know one of these is able to tell you stuff like the interface (i.e. eth0) name. And I believe I came to the conclusion when I did look into it that the ifcfg-rh plugin did try to use it. > > ifnet does not, so the question is which distributions that uses ifnet... > > But that plugin is maybe fully handled upstream? > > If “fully handled” is a synonym to “nobody really cares” then yes. Upstream > doesn't care about distribution specific plugins unless someone keen on that > distribution sends patches, at the least. A maintainer of the specific > plugin would be better, of course. Eh... I said "fully handled upstream", not "fully handled by upstream". The different in wording is small, but the impact is huge. The first version which was the question I asked was if what I find in the networkmanager git repo is the latest ifnet code, or if they are developing it elsewhere before pushing upstream. The second one (which I DID NOT ask) is if upstream develops the ifnet plugin. So the question really was "are there any more distributions using ifnet other then gentoo we need to collaborate with, and if I want to hack on it, will I find the code in the networkmanager upstream git, or do I have to find a devtree somewhere else first"?
Is this still failing with 0.9.8.2?
(In reply to Pacho Ramos from comment #7) > Is this still failing with 0.9.8.2?
