Bug 502142 - NM_CONTROLLED=no doesn't work when link comes up
NM_CONTROLLED=no doesn't work when link comes up
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-22 04:28 EDT by Mads Kiilerich
Modified: 2009-11-11 12:31 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-11 12:31:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mads Kiilerich 2009-05-22 04:28:57 EDT
Description of problem:

I would like to use NetworkManager for wireless and static configuration for the wired connection. It is my understanding that that setup should work and I have /etc/sysconfig/network-scripts/ifcfg-eth0 :
DEVICE=eth0
ONBOOT=yes
PEERDNS=no
NM_CONTROLLED=no
BOOTPROTO=static
BROADCAST=172.16.16.255
IPADDR=172.16.16.1
NETMASK=255.255.255.0
NETWORK=172.16.16.0

NM_CONTROLLED is read correctly when NM is started without link on eth0:
May 22 17:08:49 localhost nm-system-settings:    ifcfg-rh:     read connection 'System eth0'
May 22 17:08:49 localhost nm-system-settings:    ifcfg-rh: Ignoring connection 'System eth0' and its device because NM_CONTROLLED was false.
May 22 17:08:49 localhost nm-system-settings:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-lo ...
May 22 17:08:50 localhost nm-system-settings: Added default wired connection 'Auto eth0' for /org/freedesktop/Hal/devices/net_00_1e_37_84_97_74

But when link appears then NM starts running dhclient:
May 22 17:11:15 localhost kernel: 0000:00:19.0: eth0: Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
May 22 17:11:15 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
May 22 17:11:15 localhost NetworkManager: <info>  (eth0): carrier now ON (device state 2)
May 22 17:11:15 localhost NetworkManager: <info>  (eth0): device state change: 2 -> 3
May 22 17:11:15 localhost NetworkManager: <info>  Activation (eth0) starting connection 'Auto eth0'
May 22 17:11:15 localhost NetworkManager: <info>  (eth0): device state change: 3 -> 4
May 22 17:11:15 localhost NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
May 22 17:11:15 localhost NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) started...
May 22 17:11:15 localhost NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) scheduled...
May 22 17:11:15 localhost NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) complete.
May 22 17:11:15 localhost NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) starting...
May 22 17:11:15 localhost NetworkManager: <info>  (eth0): device state change: 4 -> 5
May 22 17:11:15 localhost NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) successful.
May 22 17:11:15 localhost NetworkManager: <info>  Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled.
May 22 17:11:15 localhost NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) complete.
May 22 17:11:15 localhost NetworkManager: <info>  Activation (eth0) Stage 3 of 5 (IP Configure Start) started...
May 22 17:11:15 localhost NetworkManager: <info>  (eth0): device state change: 5 -> 7
May 22 17:11:15 localhost NetworkManager: <info>  Activation (eth0) Beginning DHCP transaction.
May 22 17:11:15 localhost NetworkManager: <info>  dhclient started with pid 3805
May 22 17:11:15 localhost NetworkManager: <info>  Activation (eth0) Stage 3 of 5 (IP Configure Start) complete.
May 22 17:11:15 localhost dhclient: Internet Systems Consortium DHCP Client 4.0.0
May 22 17:11:15 localhost dhclient: Copyright 2004-2007 Internet Systems Consortium.
May 22 17:11:15 localhost dhclient: All rights reserved.
May 22 17:11:15 localhost dhclient: For info, please visit http://www.isc.org/sw/dhcp/
May 22 17:11:15 localhost dhclient: 
May 22 17:11:15 localhost NetworkManager: <info>  DHCP: device eth0 state changed (null) -> preinit
May 22 17:11:15 localhost dhclient: Listening on LPF/eth0/00:1e:37:84:97:74
May 22 17:11:15 localhost dhclient: Sending on   LPF/eth0/00:1e:37:84:97:74
May 22 17:11:15 localhost dhclient: Sending on   Socket/fallback
May 22 17:11:17 localhost avahi-daemon[3215]: Registering new address record for fe80::21e:37ff:fe84:9774 on eth0.*.
May 22 17:11:19 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
May 22 17:11:26 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
May 22 17:11:33 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
May 22 17:11:42 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13

I would expect NM_CONTROLLED=no interfaces to never be touched by NM. If they appear in NM then they should be read-only.


Version-Release number of selected component (if applicable):

NetworkManager-0.7.1-1.fc10.i386
Comment 1 Mads Kiilerich 2009-05-22 08:12:44 EDT
Some notes analysing the problem:
system-settings/plugins/ifcfg-rh/reader.c connection_from_file parses NM_CONTROLLED and stores it in *ignored, which ends up as .unmanaged and returned by nm-ifcfg-connection.c nm_ifcfg_connection_get_unmanaged.

When the interface gets link then nm-manager.c hal_manager_udi_added_cb gets called. It sees it as a "new" device creates a "new Ethernet device". 
It looks like a nm_ifcfg_connection_get_unmanaged (connection) is missing somewhere, but I get lost in the callbacks and can't figure out where and at which level it belongs.
Comment 2 Mads Kiilerich 2009-05-22 13:18:19 EDT
What happens is that nm-system-settings in plugins/ifcfg-rh/plugin.c read_one_connection() calls nm_ifcfg_connection_new() and correctly goes "Ignoring connection 'System eth0' and its device because NM_CONTROLLED was false".

But the very next moment NetworkManager in nm-manager.c handle_unmanaged_devices() no unmanaged devices are found and marked, so eth0 now becomes marked as managed and it goes "Added default wired connection 'Auto eth0' for /org/freedesktop/Hal/devices/net_00_1e_37_84_97_74"

I assume that NM_CONTROLLED=0 devices should end up as "unmanaged devices"? How should they get there? Is it a race condition in the communication between the two processes?
Comment 3 Niels Haase 2009-05-22 17:48:04 EDT
This bug has been triaged

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 4 Mads Kiilerich 2009-05-23 09:42:02 EDT
Pwew.

The problem was trigged by me not specifying HWADDR. The list of unmanaged devices is created by looking each ifcfg mac address up in HAL to get the UDI, and when no HWADDR is specified in an ifcfg file with NM_CONTROLLED=no then the disabling is silently ignored.

NM has to work together with - and thus to some extent duplicate - the functionality in /etc/sysconfig/network-scripts scripts. But rigth now NM always does what corresponds to network-functions get_config_by_hwaddr(mac_addr). But the scripts tries get_hwaddr(device_name) first, and I would expect NM to do the same.
Comment 5 Mads Kiilerich 2009-05-26 05:56:13 EDT
A patch has been posted on http://mail.gnome.org/archives/networkmanager-list/2009-May/msg00212.html
Comment 6 Dan Williams 2009-05-26 10:33:29 EDT
Thanks for the patch; however, HWADDR is mandatory.  There is no other mechanism besides MAC address to match the ifcfg to a *specific* piece of network hardware.  If HWADDR isn't present in the ifcfg file, then there is no possibility to match up the ifcfg file's settings with a specific hardware device.

Any idea why the ifcfg did not contain the HWADDR option in the first place?
Comment 7 Dan Williams 2009-11-11 12:31:38 EST
Closing worksforme since the fix was adding HWADDR, which is normally what system-config-network and anaconda do when creating connections as well.

Note You need to log in before you can comment on or make changes to this bug.