device named eth0_clashed during swapping

[Crispin Flowerday]

I have a hunch that this is due to linux-wlan-ng and some other drivers not giving the network device a mac address until after it's added

Using the latest version if udev (079-0ubuntu10), I ended up with a network card called 'eth0_clashed' after bootup.

/etc/iftab:

# This file assigns persistent names to network interfaces. See iftab(5).
eth0 mac 00:0d:60:80:d7:ce

ifconfig -a

eth0 Link encap:Ethernet HWaddr 00:0D:60:80:D7:CE
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

eth0_clas Link encap:Ethernet HWaddr 00:12:F0:5D:BC:BD
          inet addr:192.168.0.9 Bcast:192.168.0.255 Mask:255.255.255.0
          inet6 addr: fe80::212:f0ff:fe5d:bcbd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:133 errors:0 dropped:0 overruns:0 frame:0
          TX packets:113 errors:0 dropped:0 overruns:0 carrier:1
          collisions:0 txqueuelen:1000
          RX bytes:29303 (28.6 KiB) TX bytes:12519 (12.2 KiB)
          Interrupt:11 Base address:0x4000 Memory:c0200000-c0200fff

Ideally this network card (the one without an entry in /etc/iftab) would end up as eth1

[Kristoffer Lundén (kristoffer-lunden)]

Ongoing discussion here: http://www.ubuntuforums.org/showthread.php?t=128276

Got this one too, but I that thanks to the bug where the interfaces switch, I was able to reboot myself online. ;-)

udev version: 079-0ubuntu10 (some say 079-0ubuntu8 worked, but that 079-0ubuntu9 had the same error).

Interfaces are properly detected at boot it seems, and my iftab looks like this:

# This file assigns persistent names to network interfaces. See iftab(5).
eth0 mac 00:13:ce:71:91:42
eth1 mac 00:03:0d:39:4b:36

It's autogenerated I assume since I haven't created it. It is also, however utterly ignored since interfaces switch and clash.

ifconfig -a looked like this:

eth1 Link encap:Ethernet HWaddr 00:03:0D:39:4B:36
          BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
          Interrupt:217 Base address:0xc00

eth1_clas Link encap:Ethernet HWaddr 00:13:CE:71:91:42
          BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:1855 errors:0 dropped:0 overruns:0 frame:0
          TX packets:449 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
          Interrupt:217 Base address:0x2000 Memory:fa9fe000-fa9fefff

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:7 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:372 (372.0 b) TX bytes:372 (372.0 b)

sit0 Link encap:IPv6-in-IPv4
          NOARP MTU:1480 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

As you can see, iftab entry for eth0 gets eth1 address, and then eth1 entry gets it too - and clashes.

Please inform if more data is needed.

[Martin Pitt (pitti)]

Scott, I think this is the same bug that we just talked about.

First, my iftab:
eth0 mac 00:06:4f:06:80:7c
eth1 mac 00:0f:ea:ea:28:b0

that's the intended order, which I get if I blacklist the modules and load them manually (or rmmod them and modprobe again).

When it works, I get: (cropped ifconfig -a output)
eth0 Link encap:Ethernet HWaddr 00:06:4F:06:80:7C
eth1 Link encap:Ethernet HWaddr 00:0F:EA:EA:28:B0

When it doesn't work, I get:
eth1_clas Link encap:Ethernet HWaddr 00:06:4F:06:80:7C
eth1 Link encap:Ethernet HWaddr 00:0F:EA:EA:28:B0

I also did the 'enable udev logging' dance, this is the condensed result:

$ grep rename log-blacklist-works/syslog
Feb 13 17:22:23 (none) udevd-event[3059]: rename_net_if: changing net interface name from 'eth0' to 'eth1'
Feb 13 17:22:23 (none) udevd-event[3059]: udev_add_device: renamed netif to 'eth1'

$ grep rename log-noblacklist-broken/syslog
Feb 13 17:03:58 (none) udevd-event[3484]: rename_net_if: changing net interface name from 'eth1' to 'eth1_clashed'
Feb 13 17:03:58 (none) udevd-event[3484]: udev_add_device: renamed netif to 'eth1_clashed'
Feb 13 17:03:58 (none) udevd-event[3496]: rename_net_if: changing net interface name from 'eth0' to 'eth1'
Feb 13 17:03:58 (none) udevd-event[3496]: udev_add_device: renamed netif to 'eth1'

So it seems that it sometimes forgets to rename the _clashed interface to the final name?

I will attach the full syslogs (starting from udevd --daemon) for reference.

[Martin Pitt (pitti)]

full syslog with UDEV_LOG=info when it happens to work (or, when blacklisting the modules and loading them manually)

[Martin Pitt (pitti)]

syslog with udev debugging when getting name clashes

[Scott James Remnant (Canonical) (canonical-scott)]

udev doesn't generate the _clashed name, iftab_helper does if the mac address of the card just added doesn't appear in /etc/iftab

Is it possible that your card doesn't have a mac address when it's inserted? I recall you're using wlan-ng? What drivers/cards are other people experiencing this bug using?

[Scott James Remnant (Canonical) (canonical-scott)]

A quick "knowledge base" of how this is supposed to all work ...

When you install Ubuntu, the installer (specifically "netcfg") iterates the network cards plugged in with drivers loaded and writes the MAC address of each to the /etc/iftab file of the installed system.

This file looks a bit like this:

eth0 mac 01:23:45:67:89:ab
eth1 mac 99:88:77:66:55:44

And says that those kernel names are reserved for cards with those MAC addresses.

When network cards turn up during the boot process, udev calls iftab_helper and passes it the name the kernel just assigned ("eth" plus the next available number) and the MAC address. iftab_helper looks it up in this file and:

IF the MAC address is in the file, returns the name the file assigned to it.
OTHERWISE IF the NAME is in the file, appends "_clashed" to the name.

So if you're seeing eth0_clashed it means you've assigned the kernel name "eth0" to a different device, and you haven't assigned any name to the imposter; easy solution is to edit /etc/iftab and add the imposter to this file or remove the static name for eth0.

("_clashed" is a temporary solution, it'll actually just use the next number in sequence -- so eth0_clashed would be eth2, eth3, etc. or even eth1 if that's not allocated -- but I wanted them to show up better first until this is fully debugged!)

NOW if you have both MAC addresses in the file, and you end up with ethN and ethN_clashed, then we have a bug. I have a hunch this is driver-specific, and probably means that the card doesn't actually have a MAC address when the network subsystem generates the add event. Please add information to the launchpad bug detailing what your card is, and what driver it uses. If you can add the following to the top of /etc/udev/rules.d/25-iftab.rules and provide the output, that'd be helpful:

SUBSYSTEM=="net", ACTION=="add", RUN+="/bin/sh -c 'echo %k $sysfs{address} >> /var/run/devices.log'"

It's also worth detailing how we do interface swapsies (if you don't get bit by the above problem), there's at least one known bug here with Atheros/madwifi-ng cards where the kernel gets a wedgie, but I think I have that in hand.

We start off with eth0 and eth1, which iftab says are both exactly the wrong way round; separate processes are dealing with eth0 and eth1, so there's no "logical" order to this.

We rename both to *_ifrename (so eth0 becomes eth0_ifrename), then we loop trying to rename them to their destination name. In theory this means we're not blocking on each other. Once the rename succeeds (or fails with something other than EEXIST) we exit the loop.

The "known bug" is that sometimes the final rename attempt returns ENODEV instead, and then both names are invalid and the kernel gets very confused. I've only seen this with madwifi-ng so far, the obvious symptom is that ifconfig itself bombs out with "No such device" any time you try and run it, even with -a.

Why do we do all of this? Simple: without it it's pretty much random as to the order network cards get assigned their names on boot. You're effectively racing on the PCI bus with the modern kernel, if "nominal eth0" needs firmware, the "nominal eth1" might beat it to getting the cove...

[Martin Pitt (pitti)]

Hi Scott!

Scott James Remnant [2006-02-13 20:00 -0000]:
> udev doesn't generate the _clashed name, iftab_helper does if the mac
> address of the card just added doesn't appear in /etc/iftab
>
> Is it possible that your card doesn't have a mac address when it's
> inserted? I recall you're using wlan-ng?

No, on my desktop I only have two genuine hardware ethernet cards, one
RealTek 8139 (there are few cards which are even more common :) ), and
one on-board Gitabit adapter with some nvidia chipset (driven by skge
or sk98lin).

Might the fact that there are two different drivers which could drive
that second card have anything to do with that bug? Also, there are
so many people who have that problem that I don't really believe in
some strange corner-case hardware reason.

Thanks,

Martin

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntulinux.org
Debian Developer http://www.debian.org

[Martin Pitt (pitti)]

Bah, I sent this via mail yesterday, and it didn't arrive yet, so let's paste:

Hi Scott!

Scott James Remnant [2006-02-13 20:00 -0000]:
> udev doesn't generate the _clashed name, iftab_helper does if the mac
> address of the card just added doesn't appear in /etc/iftab
>
> Is it possible that your card doesn't have a mac address when it's
> inserted? I recall you're using wlan-ng?

No, on my desktop I only have two genuine hardware ethernet cards, one RealTek 8139 (there are few cards which are even more common :) ), and one on-board Gitabit adapter with some nvidia chipset (driven by skge or sk98lin).

Might the fact that there are two different drivers which could drive that second card have anything to do with that bug? Also, there are so many people who have that problem that I don't really believe in some strange corner-case hardware reason.

Thanks,

Martin

[Scott James Remnant (Canonical) (canonical-scott)]

Shouldn't be, the code is simple enough that if you're getting _clashed it literally means that the MAC address your card has isn't in the iftab file; I'm not aware of any escapism or errors there.

Adding the logging stanza would be helpful to get an idea of what's being run

[Scott James Remnant (Canonical) (canonical-scott)]

Never blame hardware or drivers when one can blame a humble developer's inability to code.

[Patrice Vetsel (vetsel-patrice)]

Sorry but with the ubuntu12 i still have a problem.
Network card -> eth1
Wifi -> eth0_clashed
:(

[Patrice Vetsel (vetsel-patrice)]

Sorry for the perturbation. My bug isn't really the same here. I fill another bug.

[Spectrum520 (gerardo-velazquez)]

Hi. I'm a new user. But I really interesting because I have the same problem with my Network Card and I can't connect to Internet. Could someone help me

[Emmanuel Mortier (emmort)]

I suppose my bug is the same but not fixed with the beta2 (Dapper drake).

The Wifi card Lucent Technologies (Orinoco) don't work now but work fine on 5.10. (So I can contact you).

With the live CD, it works fine. It works during the installation too and seems correctly detected. But I see the "power" light was off when I use the network configuration tool.

As soon I will configure the card (iwconfig,...) the "power light" fall down and light with the active light only. So it seems out of power xhen the answer comes.

I suspect a problem with the pcmcia control software or module.