Bug 499583 - NetworkManager does not respect NM_CONTROLLED=no
NetworkManager does not respect NM_CONTROLLED=no
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: NetworkManager (Show other bugs)
5.3
All Linux
low Severity medium
: rc
: ---
Assigned To: Dan Williams
desktop-bugs@redhat.com
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-07 06:20 EDT by Simon Matter
Modified: 2013-07-11 13:22 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 465847
Environment:
Last Closed: 2013-07-11 13:22:04 EDT
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 Simon Matter 2009-05-07 06:20:19 EDT
+++ This bug was initially created as a clone of Bug #465847 +++

***
It seem like this bug still exists in NetworkManager-0.7.0 from RHEL5.3. I've tried to find a patch - in the Fedora RPMS and in NetworkManager git tree - but failed. Now that it's fixed in Fedora would you mind doing so in the next RHEL release? It would make NM usable for us.
***

Created an attachment (id=319578)
Network configuration. (ifcfg-eth?, ifcfg-vbr?)

Description of problem:
I'm setting up a hybrid bridged / wired / wireless network on my laptop.
I want NM to control two devices - br0 (bridged to eth0) and wlan0 - nothing else.
However, even-though ifcfg-eth[0/1] and ifcfg-vbr1 have NM_CONTROLLED=no, 

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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
$ grep NM_CONTROLLED= /etc/sysconfig/network-scripts/ifcfg-*
/etc/sysconfig/network-scripts/ifcfg-eth0:NM_CONTROLLED=no
/etc/sysconfig/network-scripts/ifcfg-eth1:NM_CONTROLLED=no
/etc/sysconfig/network-scripts/ifcfg-vbr0:NM_CONTROLLED=yes
/etc/sysconfig/network-scripts/ifcfg-vbr1:NM_CONTROLLED=no

$ grep BRIDGE= /etc/sysconfig/network-scripts/ifcfg-*
/etc/sysconfig/network-scripts/ifcfg-eth0:BRIDGE=br0
/etc/sysconfig/network-scripts/ifcfg-eth1:BRIDGE=br1

$ /etc/init.d/network start
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:                                [  OK  ]
Bringing up interface eth1:                                [  OK  ]
Bringing up interface vbr0:                                        
Determining IP information for br0... done.                [  OK  ]
Bringing up interface vbr1:                                [  OK  ]

$ ifconfig | egrep -e 'br|eth' -A2
br0       Link encap:Ethernet  HWaddr 00:1C:25:7E:BA:29
          inet addr:192.168.2.6  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::21c:25ff:fe7e:ba29/64 Scope:Link
--
br1       Link encap:Ethernet  HWaddr 00:E0:98:33:72:51
          inet6 addr: fe80::2e0:98ff:fe33:7251/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
--
eth0      Link encap:Ethernet  HWaddr 00:1C:25:7E:BA:29
          inet6 addr: fe80::21c:25ff:fe7e:ba29/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
--
eth1      Link encap:Ethernet  HWaddr 00:E0:98:33:72:51
          inet6 addr: fe80::2e0:98ff:fe33:7251/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1

$ /etc/init.d/NetworkManager start
Setting network parameters...                              [  OK  ]
Starting NetworkManager daemon:                            [  OK  ]

$ ifconfig | egrep -e 'br|eth' -A2
br0       Link encap:Ethernet  HWaddr 00:1C:25:7E:BA:29
          inet addr:192.168.2.6  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::21c:25ff:fe7e:ba29/64 Scope:Link
--
br1       Link encap:Ethernet  HWaddr 00:E0:98:33:72:51
          inet6 addr: fe80::2e0:98ff:fe33:7251/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
--
eth0      Link encap:Ethernet  HWaddr 00:1C:25:7E:BA:29
          inet addr:192.168.2.6  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::21c:25ff:fe7e:ba29/64 Scope:Link
--
eth1      Link encap:Ethernet  HWaddr 00:E0:98:33:72:51
          inet addr:172.18.130.95  Bcast:172.18.130.255  Mask:255.255.255.0
          inet6 addr: fe80::2e0:98ff:fe33:7251/64 Scope:Link

=====
Both eth0 and eth1 should not get an IP address... far worse, shouldn't NM automatically ignore bridged network devices?
=====

- Gilboa

--- Additional comment from gilboad@gmail.com on 2008-10-06 13:35:07 EDT ---

Uggh... Hit send by mistake.

Versions:
$ rpm -qa | grep NetworkManager
NetworkManager-gnome-0.7.0-0.11.svn4022.fc9.x86_64
NetworkManager-glib-0.7.0-0.11.svn4022.fc9.x86_64
NetworkManager-0.7.0-0.11.svn4022.fc9.x86_64

Easily reproducible.

--- Additional comment from gilboad@gmail.com on 2008-10-06 13:42:04 EDT ---

Created an attachment (id=319579)
Network configuration. (ifcfg-eth?, ifcfg-vbr?) [Fixed tar]

--- Additional comment from gilboad@gmail.com on 2008-10-06 13:44:12 EDT ---

$ /usr/sbin/nm-system-settings --debug --plugins=ifcfg-fedora
** Message: Loaded plugin ifcfg-fedora: (c) 2007 - 2008 Red Hat, Inc.  To report bugs please use the NetworkManager mailing list.
** Message:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-lo ...
** Message:    ifcfg-fedora:     error: Ignoring loopback device config.
** Message:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-vbr1 ...
** Message:    ifcfg-fedora:     error: Unknown connection type 'Bridge'
** Message:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-eth1 ...
** Message:    ifcfg-fedora:     read connection 'System eth1'
** Message:    ifcfg-fedora: Ignoring connection 'System eth1' and its device because NM_CONTROLLED was false.
** Message:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-vbr0 ...
** Message:    ifcfg-fedora:     error: Unknown connection type 'Bridge'
** Message:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ...
^C

(Killed because it hanged)

--- Additional comment from dcbw@redhat.com on 2008-10-15 12:54:59 EDT ---

Can you attach the output of 'lshal' as well?  I'd like to see if/how HAL detects the bridges...

--- Additional comment from gilboad@gmail.com on 2008-10-16 07:05:32 EDT ---

Created an attachment (id=320543)
lshal (NM disabled, for now)

--- Additional comment from felix.schwarz@oss.schwarz.eu on 2008-12-28 08:48:26 EDT ---

For me this worked on F10. Reporter, is this still a problem for you?

--- Additional comment from gilboad@gmail.com on 2009-02-16 06:50:10 EDT ---

I just enabled NM (under F10), and it does honor NM_CONTROLLED=no.
Bug seems to be fixed. Please close.

--- Additional comment from dcbw@redhat.com on 2009-02-17 07:00:38 EDT ---

Ok, thanks!
Comment 1 Dan Williams 2009-11-12 16:02:04 EST
I can't seem to reproduce this with your network configuration and NM 0.7.0-9.el5 from RHEL 5.4.  Both devices are correctly unmanaged by NM.  Tested in a VM with two network interfaces using your exact ifcfg files and the network interfaces assigned the MAC addresses from your configuration.

Can you let me know if this still happens for you with latest RHEL 5.4 NetworkManager updates?
Comment 2 Simon Matter 2009-11-16 10:15:00 EST
It's quite a long time ago but I just tried to reproduce the issue I had, now with NetworkManager-0.7.0-9.el5.
I'm using a 3G USB Modem which shows up as an emulated ethernet device using the cdc_ether. The whole thing is run with my own ifup-wwan script. What I don't want is that NM touches the device at all. I expected that this can be controlled with NM_CONTROLLED=no but this seems not to be the case.

This is my ifcfg-usb0:
# WWAN Mobile Broadband USB Modem
DEVICE=usb0
BOOTPROTO=dhcp
ONBOOT=no
HOTPLUG=no
USERCTL=yes
TYPE=Unknown
DEVICETYPE=wwan
NM_CONTROLLED=no
CONTROLDEVICE=/dev/ttyACM1
APN="gprs.swisscom.ch"
CREDITCHECK="*130#"
HWADDR=02:80:15:a0:03:00

Now, if NM runs and I remove network connection, I get this:

Nov 16 15:45:55 delta64 kernel: usb 5-2: new full speed USB device using uhci_hcd and address 5
Nov 16 15:45:55 delta64 kernel: usb 5-2: configuration #1 chosen from 3 choices
Nov 16 15:45:55 delta64 kernel: scsi5 : SCSI emulation for USB Mass Storage devices
Nov 16 15:45:55 delta64 kernel: cdc_acm 5-2:3.1: ttyACM0: USB ACM device
Nov 16 15:45:55 delta64 kernel: cdc_acm 5-2:3.3: ttyACM1: USB ACM device
Nov 16 15:45:55 delta64 kernel: usb0: register 'cdc_ether' at usb-0000:00:1d.0-2, CDC Ethernet Device, 02:80:15:a0:03:00
Nov 16 15:45:55 delta64 NetworkManager: <info>  usb0: driver is 'cdc_ether'. 
Nov 16 15:45:55 delta64 NetworkManager: <info>  Found new Ethernet device 'usb0'. 
Nov 16 15:45:55 delta64 NetworkManager: <info>  (usb0): exported as /org/freedesktop/Hal/devices/net_02_80_15_a0_03_00 
Nov 16 15:45:56 delta64 kernel: usb0: unregister 'cdc_ether' usb-0000:00:1d.0-2, CDC Ethernet Device
Nov 16 15:45:56 delta64 kernel: cdc_acm 5-2:3.1: ttyACM0: USB ACM device
Nov 16 15:45:56 delta64 kernel: cdc_acm 5-2:3.3: ttyACM1: USB ACM device
Nov 16 15:45:56 delta64 kernel: usb0: register 'cdc_ether' at usb-0000:00:1d.0-2, CDC Ethernet Device, 02:80:15:a0:03:00
Nov 16 15:45:56 delta64 chat[6643]: abort on (ERROR)
Nov 16 15:45:56 delta64 chat[6643]: send (AT*ENAP=0^M)
Nov 16 15:45:56 delta64 chat[6643]: expect (OK)
Nov 16 15:45:56 delta64 chat[6643]: AT*ENAP=0
Nov 16 15:45:56 delta64 chat[6643]: 
Nov 16 15:45:56 delta64 chat[6643]: 
Nov 16 15:45:56 delta64 chat[6643]: ERROR
Nov 16 15:45:56 delta64 chat[6643]:  -- failed
Nov 16 15:45:56 delta64 chat[6643]: Failed (ERROR)
Nov 16 15:45:57 delta64 chat[6721]: abort on (ERROR)
Nov 16 15:45:57 delta64 chat[6721]: send (AT+CFUN=4^M)
Nov 16 15:45:57 delta64 chat[6721]: expect (OK)
Nov 16 15:45:57 delta64 chat[6721]: AT+CFUN=4
Nov 16 15:45:57 delta64 chat[6721]: 
Nov 16 15:45:57 delta64 chat[6721]: 
Nov 16 15:45:57 delta64 chat[6721]: ERROR
Nov 16 15:45:57 delta64 chat[6721]:  -- failed
Nov 16 15:45:57 delta64 chat[6721]: Failed (ERROR)
Nov 16 15:45:58 delta64 NetworkManager: <info>  (usb0): now unmanaged 
Nov 16 15:45:59 delta64 NetworkManager: <info>  usb0: driver is 'cdc_ether'. 
Nov 16 15:45:59 delta64 NetworkManager: <info>  Found new Ethernet device 'usb0'. 
Nov 16 15:45:59 delta64 NetworkManager: <info>  (usb0): exported as /org/freedesktop/Hal/devices/net_02_80_15_a0_03_00 
Nov 16 15:46:03 delta64 nm-system-settings: Adding default connection 'Auto usb0' for /org/freedesktop/Hal/devices/net_02_80_15_a0_03_00
Nov 16 15:46:03 delta64 NetworkManager: <info>  (usb0): device state change: 1 -> 2 
Nov 16 15:46:03 delta64 NetworkManager: <info>  (usb0): bringing up device. 
Nov 16 15:46:03 delta64 NetworkManager: <info>  (usb0): preparing device. 
Nov 16 15:46:03 delta64 NetworkManager: <info>  (usb0): deactivating device (reason: 2). 
Nov 16 15:46:03 delta64 NetworkManager: <info>  Policy set 'System eth0' (eth0) as default for routing and DNS. 
Nov 16 15:46:03 delta64 NetworkManager: <info>  (usb0): carrier now ON (device state 2) 
Nov 16 15:46:03 delta64 NetworkManager: <info>  (usb0): device state change: 2 -> 3 
Nov 16 15:46:03 delta64 NetworkManager: <info>  (usb0): carrier now OFF (device state 3) 
Nov 16 15:46:03 delta64 NetworkManager: <info>  (usb0): device state change: 3 -> 2 
Nov 16 15:46:03 delta64 NetworkManager: <info>  (usb0): deactivating device (reason: 40). 
Nov 16 15:46:03 delta64 NetworkManager: <info>  Policy set 'System eth0' (eth0) as default for routing and DNS. 
Nov 16 15:46:03 delta64 NetworkManager: <WARN>  auto_activate_device(): Connection 'Auto usb0' auto-activation failed: (2) Device not managed by NetworkManager 
Nov 16 15:46:04 delta64 avahi-daemon[3353]: New relevant interface usb0.IPv6 for mDNS.
Nov 16 15:46:04 delta64 avahi-daemon[3353]: Joining mDNS multicast group on interface usb0.IPv6 with address fe80::80:15ff:fea0:300.
Nov 16 15:46:04 delta64 avahi-daemon[3353]: Registering new address record for fe80::80:15ff:fea0:300 on usb0.


In the end it say it won't auto activate the device:
Nov 16 15:46:03 delta64 NetworkManager: <WARN>  auto_activate_device(): Connection 'Auto usb0' auto-activation failed: (2) Device not managed by NetworkManager

But before is already touches the device:
Nov 16 15:46:03 delta64 NetworkManager: <info>  (usb0): bringing up device. 
Nov 16 15:46:03 delta64 NetworkManager: <info>  (usb0): preparing device. 


IIRC that was what caused problems for me and I didn't understand why this happens if I put NM_CONTROLLED=no into the config file. Did I miss something?
Comment 3 Dan Williams 2009-11-17 03:49:01 EST
So that's a Sony Ericsson or an Ericsson device which NM should handle just fine these days.  Any reason you don't want to let NM handle it?

In any case, it's probably:

TYPE=Unknown

which isn't a valid type.  Change that to TYPE=Ethernet and you should be fine.  Since it actually is an ethernet device.
Comment 4 Simon Matter 2009-11-19 03:27:04 EST
Correct, it's a Sony Ericsson MD300, which was not supported by NM at the time we implemented it. That may have changed but I'm still not sure NM supports all the features we need, like disabling roaming or checking/refill credit.

Using TYPE=Ethernet was not possible but I don't remember exactly why. I think it was because some tools, be it NM or the network init scripts, did something wrong when using it.
Comment 5 Dan Williams 2009-11-20 18:30:43 EST
Out of curiousity, how does the check/refill credit work?  You can disable roaming with NetworkManager if you set the MCC/MNC in the connection editor, which makes NM request specific registration only to that network.  That should disable roaming, but yes there are better ways to do it that RHEL5 will probably not ever support.

In any case, you could change to TYPE=Ethernet, make sure you put HWADDR there matching the MAC address of the cdc_ether net interface, and then NM will show the device in the menu, but will never do anything to the ethernet interface.

To ignore the modem devices too, you might be able to do this by:

1) editing /etc/NetworkManager/nm-system-settings.conf
2) adding ",keyfile" to the end of the plugins= line
3) adding a [keyfile] section at the bottom that that looks like:

[keyfile]
unmanaged-devices=/org/freedesktop/Hal/devices/usb_device_3f0_1f1d_noserial_if2_serial_usb_0;<other interface>;<other interface>

4) killall -TERM nm-system-settings

You pass a list of HAL UDIs in the unmanaged-devices line.  YOu can get these by doing 'lshal | less' and looking in that output for "ttyACM0" or "ttyACM1" etc.  The UDI should be at the top of the block for the device.

Let me know if that helps.
Comment 6 Dan Williams 2013-02-18 23:49:00 EST
Any update on this issue?  Does the suggestion in comment 5 work?
Comment 7 Simon Matter 2013-02-19 03:42:23 EST
Unfortunately I can't change the clients to make tests. We have them installed and centrally managed in multiple countries around the world. Some of them are using LAN, some wireless and some mobile networks and it has to work without any user intervention and no device specific configuration.
I may look at this again when we move to EL6 but that's not going to happen soon.
Comment 8 Dan Williams 2013-02-19 10:41:51 EST
When moving to RHEL6, two things will ensure you can use ifup-wwan if you like:

1) uninstall ModemManager; NM won't touch modems when ModemManager isn't running, because the WWAN stuff was split out to ModemManager.

2) We need to ensure that the MD300 WWAN card ethernet device is marked as WWAN, in which case NM will ignore it too

if both these are the case NM won't touch anything for the MD300.  If #2 is not the case ('cat /sys/class/net/usb0/uevent' and look for DEVTYPE=wwan) then we'll need to fix that in the kernel.
Comment 9 Dan Williams 2013-07-10 22:06:39 EDT
Any update on this issue?
Comment 10 Simon Matter 2013-07-11 03:21:13 EDT
Sorry, I have no update. I'm not sure we will use the MD300 at all in future because it's not available anymore. Maybe this bug could be closed then.
Comment 11 Dan Williams 2013-07-11 13:22:04 EDT
(In reply to Simon Matter from comment #10)
> Sorry, I have no update. I'm not sure we will use the MD300 at all in future
> because it's not available anymore. Maybe this bug could be closed then.

Ok, thanks for the update, closing.

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