Comment 8 for bug 592963

I have one machine which is experiencing this problem and I know of another which is having
it, too. This is a fairly bad problem with troubling security implications. Imagine a router/firewall
setup which allows people access to services internally. If the interfaces are swapped, internal
services would be exposed to the whole world. Can we boost the importance of this bug?

If I disable NetworkManager the problem goes away. I use /etc/network/interfaces to set
the network information statically. (This problem is now solved for my purposes, but it
would be a good idea to track this down for the benefit of others.)

The swap of the interfaces is intermittent. It fails maybe one in ten times. However, when
I had knockd and snort starting, it would fail much more frequently. (Both of which access
the network interface when they start.) Furthermore, I would find messages like this in /var/log/syslog:
> Nov 15 10:48:35 opdubuntu udevd[469]: changing net interface name from 'eth1' to 'eth2'
> Nov 15 10:48:35 opdubuntu udevd[469]: error changing net interface name eth1 to eth2: Device or resource busy

After disabling the start of knockd, snort, and finally NetworkManager only this message appears:
> Nov 16 10:00:33 opdubuntu udevd[384]: changing net interface name from 'eth1' to 'eth0'

I believe that what is happening is that something is seizing one or the other of the network devices
and causing udev to give up on its renaming attempt or to complete it poorly.

I looked in the sources for the udev package and found that the "changing" messages are emitted
by rename_netif() in udev-173/udev/udev-event.c:846. This routine unfortunately aggregates
multiple errors into an "out:" section at the end, so it's hard to tell exactly what went wrong. My
guess is that the ioctl() call on line 867 has failed:
> err = ioctl(sk, SIOCSIFNAME, &ifr);

Suggestion A: maybe udevd could emit a more helpful error? Something along the lines of "ioctl()
failed with device X."

/etc/udev/rules.d/70-persistent-net.rules contains and is apparently what causes the changing
of the interfaces:
> # This file was automatically generated by the /lib/udev/write_net_rules
> # program, run by the persistent-net-generator.rules rules file.
> #
> # You can modify it, as long as you keep each rule on a single
> # line, and change only the value of the NAME= key.
>
> # PCI device 0x10ec:0x8139 (8139too)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:fc:3d:42:1e", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
>
> # PCI device 0x14e4:0x170c (b44)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:13:72:32:43:e9", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

That file is generated automatically by /lib/udev/rules.d/75-persistent-net-generator.rules. However,
I find a curious prohibition in udev(7):
> NAME
> What a network interface should be named.
>
> Also, as a temporary workaround, this is what a device node should
> be named; usually the kernel provides the defined node name or
> creates and removes the node before udev even receives any event.
> Changing the node name from the kernel's default creates
> inconsistencies and is not supported. If the kernel and NAME
> ^^^^^^^^^^^^^^^^^
> specify different names, an error is logged. udev is only expected
> to handle device node permissions and to create additional
> symlinks, not to change kernel-provided device node names. Instead
> of renaming a device node, SYMLINK should be used. However, symlink
> names must never conflict with device node names, as that would
> result in unpredictable behavior.

Suggestion B: 70-persistent-net.rules should not be renaming devices.

Suggestion C: Given udevd's central importance, it should not offer services
that it cannot support.

Suggestion D: Services like NetworkManager or the ones in /etc/init.d should
not be started until udevd has done its work. (Alternately, udevd might only
open devices once and keep control of them until it is done with them.)

I'm not sure what to do next with this bug, suggestions are welcome!

$ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 11.10
> Release: 11.10
> Codename: oneiric

(FWIW, the other machine suffering this problem is running 10.04, but I don't have access to it.)