Bug 691327

Summary: makes wrong choices, etc
Product: [Fedora] Fedora Reporter: udo <udovdh>
Component: NetworkManagerAssignee: Lubomir Rintel <lkundrak>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 23CC: dcbw, dwayne
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-19 20:19:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description udo 2011-03-28 09:17:38 UTC
Description of problem:
Updated to NetworkManager-0.8.3.998-2.fc14.x86_64.
Manually restarted NetworkManager service afterwards.
NM gave eth0 the very same IP as usb0, being the IP that normally only sits on usb0.
Also it changed my resolv.conf into an almost empty config so that DNS would not work if the IP-numbering would be OK.
ifcfg-eth0 has the right settings as `service network restart` sets stuff up perfectly.

Version-Release number of selected component (if applicable):
NetworkManager-0.8.3.998-2.fc14.x86_64

How reproducible:
Have box with working and correctly set up eth0, usb0. Update to said version.


Steps to Reproduce:
1. See above.
2.
3.
  
Actual results:
[root@surfplank2 mesa]# cat /etc/resolv.conf
# Generated by NetworkManager
search hierzo


# No nameservers found; try putting DNS servers into your
# ifcfg files in /etc/sysconfig/network-scripts like so:
#
# DNS1=xxx.xxx.xxx.xxx
# DNS2=xxx.xxx.xxx.xxx
# DOMAIN=lab.foo.com bar.foo.com
[root@surfplank2 mesa]# vi /etc/sysconfig/network-scripts/ifcfg-eth0 
[root@surfplank2 mesa]# rpm -q NetworkManager
NetworkManager-0.8.3.998-2.fc14.x86_64

[root@surfplank2 mesa]# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:1F:D0:B1:F8:36  
          inet addr:192.168.0.200  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: 2001:980:3480:0:21f:d0ff:feb1:f836/64 Scope:Global
          inet6 addr: fe80::21f:d0ff:feb1:f836/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:7200  Metric:1
          RX packets:187770137 errors:0 dropped:118 overruns:0 frame:0
          TX packets:210792699 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:63376276669 (59.0 GiB)  TX bytes:146219012463 (136.1 GiB)
          Interrupt:40 Base address:0x4000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:2528746 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2528746 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:400568465 (382.0 MiB)  TX bytes:400568465 (382.0 MiB)

usb0      Link encap:Ethernet  HWaddr 22:B6:AF:EF:F4:BE  
          inet addr:192.168.0.200  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::20b6:afff:feef:f4be/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:171 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6367 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:17358 (16.9 KiB)  TX bytes:310367 (303.0 KiB)



Expected results:
Correct config.

Additional info:
after `service network restart` corrected the network settings, a start of the NetworkManager service messes up the config again.
Updating to the previous version worked without this flaw.
usb0 is connected to an iPaq and the fake hardware address does appeat to change every time, so please take that into account.

Mar 28 11:00:47 surfplank2 NetworkManager[16280]: <info> caught signal 15, shutting down normally.
Mar 28 11:00:47 surfplank2 NetworkManager[16280]: <info> exiting (success)
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> NetworkManager (version 0.8.3.998-2.fc14) is starting...
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Read config file /etc/NetworkManager/NetworkManager.conf
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> modem-manager is now available
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> monitoring kernel firmware directory '/lib/firmware'.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]:    ifcfg-rh: Acquired D-Bus service com.redhat.ifcfgrh1
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Loaded plugin ifcfg-rh: (c) 2007 - 2010 Red Hat, Inc.  To report bugs please use the NetworkManager mailing list.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... 
Mar 28 11:00:48 surfplank2 NetworkManager[29931]:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-usb0 ... 
Mar 28 11:00:48 surfplank2 NetworkManager[29931]:    ifcfg-rh:     warning: NM_CONTROLLED was false but HWADDR or SUBCHANNELS was missing; device will be managed
Mar 28 11:00:48 surfplank2 NetworkManager[29931]:    ifcfg-rh:     read connection 'System usb0'
Mar 28 11:00:48 surfplank2 NetworkManager[29931]:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ... 
Mar 28 11:00:48 surfplank2 NetworkManager[29931]:    ifcfg-rh:     read connection 'System eth0'
Mar 28 11:00:48 surfplank2 NetworkManager[29931]:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-usb1 ... 
Mar 28 11:00:48 surfplank2 NetworkManager[29931]:    ifcfg-rh:     warning: NM_CONTROLLED was false but HWADDR or SUBCHANNELS was missing; device will be managed
Mar 28 11:00:48 surfplank2 NetworkManager[29931]:    ifcfg-rh:     read connection 'System usb1'
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> WiFi enabled by radio killswitch; enabled by state file
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> WWAN enabled by radio killswitch; enabled by state file
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> WiMAX enabled by radio killswitch; enabled by state file
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Networking is enabled by state file
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> (eth0): carrier is ON
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> (eth0): new Ethernet device (driver: 'r8169' ifindex: 2)
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> (eth0): exported as /org/freedesktop/NetworkManager/Devices/0
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> (eth0): now managed
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> (eth0): device state change: 1 -> 2 (reason 41)
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> (eth0): preparing device.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (eth0) starting connection 'System eth0'
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> (eth0): device state change: 2 -> 7 (reason 0)
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <error> [1301302848.537362] [nm-device-ethernet.c:764] real_update_permanent_hw_address(): (usb0): unable to read permanent MAC address (error 0)
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> (usb0): carrier is ON
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> (usb0): new Ethernet device (driver: 'cdc_subset' ifindex: 3)
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> (usb0): exported as /org/freedesktop/NetworkManager/Devices/1
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> (usb0): now managed
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> (usb0): device state change: 1 -> 2 (reason 41)
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> (usb0): preparing device.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (usb0) starting connection 'System usb0'
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> (usb0): device state change: 2 -> 7 (reason 0)
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (usb0) Stage 3 of 5 (IP Configure Start) scheduled.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) started...
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) scheduled...
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Beginning IP6 addrconf.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) complete.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (usb0) Stage 3 of 5 (IP Configure Start) started...
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (usb0) Stage 4 of 5 (IP4 Configure Get) scheduled...
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (usb0) Stage 3 of 5 (IP Configure Start) complete.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) started...
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Scheduling stage 5
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Done scheduling stage 5
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) complete.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (usb0) Stage 4 of 5 (IP4 Configure Get) started...
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Scheduling stage 5
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (usb0) Stage 5 of 5 (IP Configure Commit) scheduled...

Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> WiFi enabled by radio killswitch; enabled by state file
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> WWAN enabled by radio killswitch; enabled by state file
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> WiMAX enabled by radio killswitch; enabled by state file

Everything is wired here, so how come this? ^^^^

Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (usb0) Stage 5 of 5 (IP Configure Commit) scheduled...
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Done scheduling stage 5
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (usb0) Stage 4 of 5 (IP4 Configure Get) complete.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 4 of 5 (IP6 Configure Get) scheduled...
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (usb0) Stage 5 of 5 (IP Configure Commit) started...
Mar 28 11:00:48 surfplank2 avahi-daemon[31631]: Withdrawing address record for 2001:980:3480:0:21f:d0ff:feb1:f836 on eth0.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> (usb0): device state change: 7 -> 8 (reason 0)
Mar 28 11:00:48 surfplank2 avahi-daemon[31631]: Registering new address record for fe80::21f:d0ff:feb1:f836 on eth0.*.
Mar 28 11:00:48 surfplank2 avahi-daemon[31631]: Withdrawing address record for fe80::21f:d0ff:feb1:f836 on eth0.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (usb0) successful, device activated.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (usb0) Stage 5 of 5 (IP Configure Commit) complete.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 4 of 5 (IP6 Configure Get) started...
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) scheduled...
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 4 of 5 (IP6 Configure Get) complete.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) started...
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> (eth0): device state change: 7 -> 8 (reason 0)
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Policy set 'System eth0' (eth0) as default for IPv4 routing and DNS.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Policy set 'System eth0' (eth0) as default for IPv6 routing and DNS.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (eth0) successful, device activated.
Mar 28 11:00:48 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) complete.
Mar 28 11:00:49 surfplank2 ntpd[19964]: Deleting interface #15 eth0, fe80::21f:d0ff:feb1:f836#123, interface stats: received=0, sent=0, dropped=0, active_time=579889 secs
Mar 28 11:00:49 surfplank2 ntpd[19964]: Deleting interface #14 eth0, 2001:980:3480:0:21f:d0ff:feb1:f836#123, interface stats: received=5942, sent=5942, dropped=0, active_time=579889 secs
Mar 28 11:00:49 surfplank2 ntpd[19964]: fd00:c0a8:a00:1::1 interface 2001:980:3480:0:21f:d0ff:feb1:f836 -> (null)
Mar 28 11:00:50 surfplank2 NetworkManager[29931]: <info> (eth0): device state change: 8 -> 9 (reason 5)
Mar 28 11:00:50 surfplank2 NetworkManager[29931]: <warn> Activation (eth0) failed.
Mar 28 11:00:50 surfplank2 NetworkManager[29931]: <info> (eth0): device state change: 9 -> 3 (reason 0)
Mar 28 11:00:50 surfplank2 NetworkManager[29931]: <info> (eth0): deactivating device (reason: 0).
Mar 28 11:00:50 surfplank2 avahi-daemon[31631]: Withdrawing address record for 192.168.10.70 on eth0.
Mar 28 11:00:50 surfplank2 avahi-daemon[31631]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.10.70.
Mar 28 11:00:50 surfplank2 avahi-daemon[31631]: Interface eth0.IPv4 no longer relevant for mDNS.
Mar 28 11:00:50 surfplank2 avahi-daemon[31631]: Registering new address record for fe80::21f:d0ff:feb1:f836 on eth0.*.
Mar 28 11:00:51 surfplank2 ntpd[19964]: Listen normally on 16 eth0 fe80::21f:d0ff:feb1:f836 UDP 123
Mar 28 11:00:51 surfplank2 ntpd[19964]: Deleting interface #13 eth0, 192.168.10.70#123, interface stats: received=10709, sent=10709, dropped=0, active_time=579891 secs
Mar 28 11:00:51 surfplank2 ntpd[19964]: 192.168.10.98 interface 192.168.10.70 -> (null)
Mar 28 11:00:51 surfplank2 ntpd[19964]: fd00:c0a8:a00:1::1 interface fe80::20b6:afff:feef:f4be -> (null)
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Activation (eth0) starting connection 'System usb0'
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> (eth0): device state change: 3 -> 4 (reason 0)
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) started...
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) scheduled...
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) complete.
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) starting...
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> (eth0): device state change: 4 -> 5 (reason 0)
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) successful.
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled.
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) complete.
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) started...
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> (eth0): device state change: 5 -> 7 (reason 0)
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) scheduled...
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) complete.
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) started...
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Scheduling stage 5
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) scheduled...
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Done scheduling stage 5
Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) complete.

Mar 28 11:00:53 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) started...
Mar 28 11:00:53 surfplank2 avahi-daemon[31631]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.0.200.
Mar 28 11:00:53 surfplank2 avahi-daemon[31631]: New relevant interface eth0.IPv4 for mDNS.
Mar 28 11:00:53 surfplank2 avahi-daemon[31631]: Registering new address record for 192.168.0.200 on eth0.IPv4.
Mar 28 11:00:54 surfplank2 NetworkManager[29931]: <info> (eth0): device state change: 7 -> 8 (reason 0)
Mar 28 11:00:54 surfplank2 NetworkManager[29931]: <info> Activation (eth0) successful, device activated.
Mar 28 11:00:54 surfplank2 NetworkManager[29931]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) complete.
Mar 28 11:00:54 surfplank2 avahi-daemon[31631]: Registering new address record for 2001:980:3480:0:21f:d0ff:feb1:f836 on eth0.*.
Mar 28 11:00:54 surfplank2 avahi-daemon[31631]: Withdrawing address record for fe80::21f:d0ff:feb1:f836 on eth0.

Comment 1 udo 2011-03-28 13:01:33 UTC
Once we run into this NM issue we stop NM, restart network service and have networking back.
But we missed that sendmail stopped delivering messages to the outside world because of this.
(i.e.: thunderbird -> sendmail -> MX receiver...)

So new emails end up in some queue.
We have to restart sendmail as well to get things going.

How `enterprise` is that?
I mean: network is back, it even works, so why not retry sending emails. Why exit anyway? Or why not fix that with the nice /etc/rc.d/init.d levels?

The machine is supposed to fix that for me, not me.

Comment 2 Dan Williams 2011-04-06 15:50:01 UTC
If you want to make sure that a configuration only applies to a single interface, you need to use HWADDR to lock the configuration to that specific interface using the interface's MAC address.  The log line here indicates that:

Mar 28 11:00:48 surfplank2 NetworkManager[29931]:    ifcfg-rh: parsing
/etc/sysconfig/network-scripts/ifcfg-usb1 ... 
Mar 28 11:00:48 surfplank2 NetworkManager[29931]:    ifcfg-rh:     warning:
NM_CONTROLLED was false but HWADDR or SUBCHANNELS was missing; device will be
managed

which says that ifcfg-usb1 does not have the HWADDR line matching the configuration with a specific piece of network hardware using the MAC address of that hardware.  If you add that line (HWADDR=xx:xx:xx:xx:xx:xx) then NM will not apply that configuration to any interface except the one that owns that MAC address.  When you do this, does it produce the result you expect?

For the WiMAX bit, the kernel says you've got an rfkill (ie Airplane mode) switch for wimax, so NM is simply reporting that fact.

Comment 3 udo 2011-04-06 16:37:11 UTC
The hardware address of the iPAQ running Linux is fake and non constant.

Why doesn't let NM make ME be in control of the system?
That is how this situation is perceived.

Comment 4 udo 2011-06-02 11:48:39 UTC
If I put the ever changing HWaddress of usb0 in /etc/sysconfig/ifcfg-usb0 and start NetWorkmanager then eth0 is robbed from the IPv4 number it had in a 100% working network setup. (`service network restart` does work 100%)
Only the ipv6 number remains.
ifcgf-eth0 does have a HWaddress.
usb1 is not even up or configured nor has a device attached.
Why is NM so destructive?

Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> NetworkManager (version 0.8.4-1.fc14) is starting...
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Read config file /etc/NetworkManager/NetworkManager.conf
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> modem-manager is now available
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> monitoring kernel firmware directory '/lib/firmware'.
Jun  2 13:38:25 surfplank2 NetworkManager[8425]:    ifcfg-rh: Acquired D-Bus service com.redhat.ifcfgrh1
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Loaded plugin ifcfg-rh: (c) 2007 - 2010 Red Hat, Inc.  To report bugs please use the NetworkManager mailing list.
Jun  2 13:38:25 surfplank2 NetworkManager[8425]:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... 
Jun  2 13:38:25 surfplank2 NetworkManager[8425]:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-usb0 ... 
Jun  2 13:38:25 surfplank2 NetworkManager[8425]:    ifcfg-rh:     read connection 'System usb0'
Jun  2 13:38:25 surfplank2 NetworkManager[8425]:    ifcfg-rh: Ignoring connection 'System usb0' and its device due to NM_CONTROLLED/BRIDGE/VLAN.
Jun  2 13:38:25 surfplank2 NetworkManager[8425]:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ... 
Jun  2 13:38:25 surfplank2 NetworkManager[8425]:    ifcfg-rh:     read connection 'System eth0'
Jun  2 13:38:25 surfplank2 NetworkManager[8425]:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-usb1 ... 
Jun  2 13:38:25 surfplank2 NetworkManager[8425]:    ifcfg-rh:     warning: NM_CONTROLLED was false but HWADDR or SUBCHANNELS was missing; device will be managed
Jun  2 13:38:25 surfplank2 NetworkManager[8425]:    ifcfg-rh:     read connection 'System usb1'
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> WiFi enabled by radio killswitch; disabled by state file
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> WWAN enabled by radio killswitch; disabled by state file
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> WiMAX enabled by radio killswitch; enabled by state file
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Networking is enabled by state file
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> (eth0): carrier is ON
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> (eth0): new Ethernet device (driver: 'r8169' ifindex: 2)
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> (eth0): exported as /org/freedesktop/NetworkManager/Devices/0
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> (eth0): now managed
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> (eth0): device state change: 1 -> 2 (reason 41)
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> (eth0): preparing device.
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Activation (eth0) starting connection 'System eth0'
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> (eth0): device state change: 2 -> 7 (reason 0)
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled.
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <error> [1307014705.712062] [nm-device-ethernet.c:763] real_update_permanent_hw_address(): (usb0): unable to read permanent MAC address (error 0)
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> (usb0): carrier is ON
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> (usb0): new Ethernet device (driver: 'cdc_subset' ifindex: 3)
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> (usb0): exported as /org/freedesktop/NetworkManager/Devices/1
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <warn> /sys/devices/virtual/net/lo: couldn't determine device driver; ignoring...
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) started...
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) scheduled...
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Beginning IP6 addrconf.
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) complete.
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) started...
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Scheduling stage 5
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Done scheduling stage 5
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) complete.
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 4 of 5 (IP6 Configure Get) scheduled...
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 4 of 5 (IP6 Configure Get) started...
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) scheduled...
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 4 of 5 (IP6 Configure Get) complete.
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) started...
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> (eth0): device state change: 7 -> 8 (reason 0)
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Policy set 'System eth0' (eth0) as default for IPv4 routing and DNS.
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Policy set 'System eth0' (eth0) as default for IPv6 routing and DNS.
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Activation (eth0) successful, device activated.
Jun  2 13:38:25 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) complete.
Jun  2 13:38:27 surfplank2 NetworkManager[8425]: <info> (eth0): device state change: 8 -> 9 (reason 5)
Jun  2 13:38:27 surfplank2 NetworkManager[8425]: <warn> Activation (eth0) failed.
Jun  2 13:38:27 surfplank2 NetworkManager[8425]: <info> (eth0): device state change: 9 -> 3 (reason 0)
Jun  2 13:38:27 surfplank2 NetworkManager[8425]: <info> (eth0): deactivating device (reason: 0).
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> Activation (eth0) starting connection 'System eth0'
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> (eth0): device state change: 3 -> 4 (reason 0)
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) started...
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) scheduled...
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) complete.
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) starting...
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> (eth0): device state change: 4 -> 5 (reason 0)
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) successful.
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled.
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) complete.
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) started...
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> (eth0): device state change: 5 -> 7 (reason 0)
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) scheduled...
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Beginning IP6 addrconf.
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) complete.
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) started...
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> Scheduling stage 5
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> Done scheduling stage 5
Jun  2 13:38:31 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) complete.
Jun  2 13:38:35 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 4 of 5 (IP6 Configure Get) scheduled...
Jun  2 13:38:35 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 4 of 5 (IP6 Configure Get) started...
Jun  2 13:38:35 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) scheduled...
Jun  2 13:38:35 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 4 of 5 (IP6 Configure Get) complete.
Jun  2 13:38:35 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) started...
Jun  2 13:38:37 surfplank2 NetworkManager[8425]: <info> (eth0): device state change: 7 -> 8 (reason 0)
Jun  2 13:38:37 surfplank2 NetworkManager[8425]: <info> Policy set 'System eth0' (eth0) as default for IPv4 routing and DNS.
Jun  2 13:38:37 surfplank2 NetworkManager[8425]: <info> Policy set 'System eth0' (eth0) as default for IPv6 routing and DNS.
Jun  2 13:38:37 surfplank2 NetworkManager[8425]: <info> Activation (eth0) successful, device activated.
Jun  2 13:38:37 surfplank2 NetworkManager[8425]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) complete.
Jun  2 13:38:46 surfplank2 NetworkManager[8425]: <info> caught signal 15, shutting down normally.
Jun  2 13:38:46 surfplank2 NetworkManager[8425]: <warn> quit request received, terminating...
Jun  2 13:38:46 surfplank2 NetworkManager[8425]: <info> exiting (success)

Comment 5 udo 2011-06-06 18:45:00 UTC
Also, why does NM start modem-manager?
There is no modem to manage. None configured.
There is no setting to disable this. Nothing.
We just have an extra process hanging around doing nothing except taking up RAM and perhaps some CPU.
Another choice?

Comment 6 udo 2011-07-22 12:27:24 UTC
When will someone look into this issue and do something about the problems?
Just booted and *both* eth0 and usb0 got the IPv4 number from usb0.
You can argue all you want about mac addresses but that is clearly wrong.
Also usb0 does have a different mac address every time we boot so configuring one or trying to use one for NM will not work well.

So please allow me, the user, the king of my own castle, to determine that the IP for usb0 can simply be attached to usb0. We don't need to try to do udev's work.
This way we can avoid part of the mess that NM currently creates.

Comment 7 udo 2011-09-30 09:11:50 UTC
Essentially:
- NM does udev's work which is unneccessary (tell the udev developer.,..)
- NM can't deal with a device that has an ever changing mac-address but is still called the same name by udev/kernel/etc (yes, ethernet over usb to my ipaq, talk to CDC gadget ethernet driver dev and/or Linus)
- NM has weird logic: one properly defined interface (eth0 with mac-address etc) if overwritten by info from usb0 which is configured not to be managed by NM
- This makes NM assign usb0 number to eth0 (very logial... NOT)
- This makes bootup VERY slow, despite systemd attempts (solution: disable NM 101%)
- This makes the network 101% FAIL after NM is done (the network service does a proper job, NM messes this situation up)
- This makes NM totally unusable; this is in a simple cabled ethernet solution. This is no WiFi or other 'modern' solution.
- Of course we have to fix the other problems first before looking into these core issues

Bonus:

- NM keeps a modem manager running despite that we did not configure a modem at all; no modem is present
- network service quietly gets stuff right, NM logs noisily even when stuff doesn't go wrong

Comment 8 udo 2011-10-23 09:39:31 UTC
Dan,

Half a year has passed without looking at the core of the problem.
Either let me decide what interface NM can touch or even look at.
Or make NM trust udev. (and stop doing udev's work in NM!)
Or at least fix the bug of assigning usb0 IP number to eth0 because of the lack of a usb0 hardware address for OBVIOUS reasons.

Comment 9 udo 2011-12-10 09:22:04 UTC
Whether the added hardware address helps is not important as the USB hardware address changes, even when using the same device.
It is a fake number.

So NM should not try to be udev and trust info.

And NM should not make my life worse and thus do what I say in the config.

Comment 10 Fedora End Of Life 2013-01-16 21:21:37 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Fedora End Of Life 2013-04-03 18:08:17 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 12 Fedora End Of Life 2015-01-09 16:37:33 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 13 udo 2015-01-09 16:48:03 UTC
No message of change, justr a 1.0.0 'milestone' was seen on slashdot.
I.e.: distrust of udev, distrust if a logical user, distrust of aan eye witness report, no progress.

Comment 14 dwayne@us.ibm.com 2015-07-07 15:18:27 UTC
I have seen something which might be similar to this.  In my case I'm using the IBM C4EB based on RHEL 6.6.  After a fresh install my machine has three network devices:
eth0
eth1
usb0
virbr0

The installer for IBM C4EB does not allow me to specify any network settings so by default I get DHCP for both eth0 and eth1.

A couple of things seem strange to me from the beginning.

When I click on Computer I see
Network: Wired
Using ethernet (usb0)

There is no /etc/sysconfig/network-scripts/ifcfg-usb0 on my system.

This seems strange to me because I have a USB mouse and keyboard but no USB network configured.

I wanted my host to have a static address on eth1 so I used Network Manager and found that afterwards both eth1 and usb0 have the same ip address so I could not ping my nameservers or anything else not on my network.  I suspect this is because both eth1 and usb0 are on the same network which is also where my default route is.

After reading this bugzilla report I finally guessed that if I put HWADDR= in ifcfg-eth0 and ifcfg-eth1 it might take care of my problem and it did.  Now my eth1 and usb0 have different ip addresses and usb0 is back to the way it was before.

I am suspecting there is a behavior in the Network Manager which is causing usb0 to be configured when it should not be.  Furthermore I am suspecting there is a behavior causing usb0 to be the default route when it should not be.

Comment 15 dwayne@us.ibm.com 2015-07-07 15:31:38 UTC
Note that if I create a /etc/sysconfig/network-scripts/ifcfg-usb0 including the ONBOOT="no" and HWADDR= usb0 is no longer configured which is what I would expect.

Additionally when I click on Computer I see
Network: Wired
Using ethernet (eth1)

which is also what I would expect.  From what I can tell is looks like IBM C4EB based on RHEL 6.6 would be based on Fedora 12 which I imagine is quite ancient.  I'm downloading Fedora 22 to see if I get similar results there and will update the bugzilla report.

Comment 16 dwayne@us.ibm.com 2015-07-07 18:59:50 UTC
With Fedora 22 on similar hardware I get a similar result by default.  The GUI has changed significantly so some of the details are a bit different.

When I click on "down arrow" in the upper right corner of the screen I see
USB Ethernet Connected
Ethernet (enp26s0f0) Off

I suspect this is indicating that the USB ethernet was configured by default when I did not expect it to be as I have nothing but a USB mouse and USB keyboard connected.

I have a number of network devices
enp0s26u1u3 - I suspect this is the USB ethernet. It has a 169.254.95.120 address.
enp11s0 - Not configured
enp21s0 - Not configured
enp26s0f0 - Not configured
enp26s0f1 - Not configured
lo

All 5 of these have an ifcfg-{name} in /etc/sysconfig/network-scripts so that seems like an improvement over my previous experience.

All but lo also have a HWADDR= so that seems like progress.

I edited ifcfg-enp0s26u1u3 to have ONBOOT="no" and rebooted but no ethernet was configured.

Comment 17 Fedora Admin XMLRPC Client 2015-08-18 14:57:01 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 18 Fedora End Of Life 2015-11-04 10:49:16 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 19 Fedora End Of Life 2016-07-19 20:19:16 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.