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?

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?

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.

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.

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.

Any update on this issue?  Does the suggestion in comment 5 work?

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.

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.

Any update on this issue?

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.

(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.