Bug 586427

Does the ifcfg file that contains NM_CONTROLLED=no also contain HWADDR=xx:xx... or not?  That's always been mandatory for making NM ignore a device, since devices can only be positively identified by their MAC address (or some other unique hardware ID), not device name.

This logic goes WAY too far, again.
NM_CONTROLLED is a KILL-switch. off = NO networkmanager. It saves us. It places us in control.
udev takes care of device naming.
Handle issues there, not in networkmanager.

We had this discussion before when my eth0 (with hw address!) was assigned some usb0 number.
This is borken behaviour. It is.

Please fix.

Also: If NM does not see a HW address it will confuse everything, as we have seen.[1]
So if _also_ NM_CONTROLLED is set to off, why bother and INSIST on controlling stuff that is not to be controlled, even if it could control at all?
Just keep NM off of that stuff.

Please fix the logic first, then try to improve on directions by the user.
This will make the user happy.

NM should not doubt device names. Device names are udev's domain.
So name is first choice.
A HW address is an extra check. If the name/HW don't match then complain in logs etc.
If there is no HW address and it IS to be NM_controlled, just act as configured.
Do not secondguess anything.
NOT anything, I wrote.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=550280

When you set NM_CONTROLLED=no, NM needs to know *what* device to stop controlling.  And since device names are not stable, HWADDR is the only way to determine which device should not be controlled by NetworkManager.

udev *tries* to create stable device names, but it's best-effort and does not always work.  Furthermore, devices can be renamed at runtime which breaks any scheme that uses device names.

If the device does not have a MAC address, use udev rules to assign a unique, stable MAC address to the device using a combination of USB serial number or other USB descriptors.

Seriously. Use HWADDR to lock the ifcfg to the device, and things will work.  But if NetworkManager does not fit your needs, you can also remove it or turn it off.

So were NM to use interface names, what happens if you plug another USB ethernet adapter in?  Or another iPaq?  USB enumeration is not stable, and it's very likely that whatever used to be usb0 is now usb1.  This is why you need to be using stable MAC addresses to uniquely identify the device, not device names.

*** Bug 587003 has been marked as a duplicate of this bug. ***

NM does know the name from the DEVICE=eth0 line.

Please do not ridicule the names idea as it does mention HW addresses.
The current situation is borken to say the least.
Please find a solution.

I.e.: trust udev. Or if not, work on udev so that you can trust it.
Or should I assign this issue to udev so you can explain what needs to be fixed?

see https://bugzilla.redhat.com/show_bug.cgi?id=550280#c13

Nonsense.
You say you need a HW adress to manage.
The dev did not have one.
So you manage it.
That is logic. (!?)
That is not what the user wants.
That is what we have udev for.
That is why the user got rid of NM as much as he could.