hi,

I see a strange numbering of ethernet devices with a VIA EPIA EK
board. This board has two ethernet connectors, you can see it
here: http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=420

I configured the system such that via-rhine is loaded as a module.
When doing the module load, the kernel says:

    via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
    via-rhine: Broken BIOS detected, avoid_D3 enabled.
    ACPI: PCI Interrupt 0000:00:0d.0[A] -> GSI 16 (level, low) -> IRQ 17
    eth0: VIA Rhine III at 0x1d000, 00:40:63:ee:96:56, IRQ 17.
    eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 45e1.
    ACPI: PCI Interrupt Link [ALKD] enabled at IRQ 23
    ACPI: PCI Interrupt 0000:00:12.0[A] -> Link [ALKD] -> GSI 23 (level, low) -> IRQ 18
    eth1: VIA Rhine II at 0x1ec00, 00:40:63:ee:96:55, IRQ 18.
    eth1: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000.

but, when continuing, no such eth0 or eth1 device is present (and thus, dhcpcd will
not receive any address).

an "ifconfig eth"0(eth1) will report:

    localhost ~ # ifconfig eth0
    eth0: error fetching interface information: Device not found
    localhost ~ # ifconfig eth1
    eth1: error fetching interface information: Device not found

it took a while until, just out of a feeling in my stomach, I tried "ifconfig -a",
and surprise, surprise, the ethernet devices were in fact there, *but* there
names where eth2 and eth3.

doing an "ifconig eth2 192.168....." in fact "upped" the interface, and I was
able to work with the net. after ifconfig, the kernel would say:

    eth2: link up, 100Mbps, full-duplex, lpa 0x45E1

and ifconfig -a:

    localhost ~ # ifconfig -a
    eth2      Link encap:Ethernet  HWaddr 00:40:63:EE:96:56  
              inet addr:192.168.1.23  Bcast:192.168.1.255  Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:16713 errors:0 dropped:0 overruns:0 ...
[ message continues ]

Hello.


Strange or not, correct or not - depends on the point of view.

The key word here is "udev" - check your udev rules.  Since some time
ago udev on some distros comes with rules to give persistent device
names for network interfaces.  Some time ago you had eth0 and eth1
with different hardware, and udev remembered this fact somewhere.
Now it sees new hardware, and gives it consecutive numbers, renaming
kernel devices.

/mjt
-

[ message continues ]

hu. where are the days when eth0 was eth0 ...

this means that, when I exchange a network card and replace it with a
new one, it will cost an "ethX" device name each time.

FYI, distribution is latest Gentoo.

as a friend of mine puts it:

    "Haha das is geil, das is wie bei Windows"
    "Wo er merkt, dass du ein neues Mainboard hast :)"

which translates:

    "Haha, that's randy, that's like in Windows, which
    notices that you've got a new mainboard"

Bad, bad Ferdl! How dare you compare this to M$Windows ;-)

well, Michael, thanks for the help,
herp

-

[ message continues ]

If you and/or your distribution accidentally or incidentally loaded modules in
the wrong order (which may happen in e.g. parallel-running boot scripts), you
suddenly have eth0 as eth1. Or, when you changed the PCI slots (i.e. swapped
cards around), eth0 would also suddenly become a different one. There never

In Linux, the user recognizes he got himself a new mainboard,
e.g. when the IDE chip changed and the new module is not in the initrd.



	Jan
-- 
-

[ message continues ]

but there *were* days when eth0 was eth0, if the kernel reports it as such.
now there is no eth0 at all. if I see an "eth0" from dmesg, I expect
it to be present.

Instead, udev remembers the old MAC address in 
    /etc/udev/rules.d/70-persistent-net.rules

which contains the old MAC adresses, too.

of course, that's problem with gentoo, not with the kernel.

Now I know why I never trusted udev much :-/

thanks,
herp

-

[ message continues ]

Whenever it's a problem or not is questionable too.  I mean,
ethX order depends on module loading order, or on PCI slot
number, or whatnot.  So userspace (udev) tries to compensate
(sometimes its own design.. issues - module loading order
in this case).  It's worse if you'll have eth0 and eth1
swapped on every boot depending on tiny module loading
time differences.

To me it'd be a problem, but I don't run udev (more,
I hate udev ;)

By the way, this very approach (renaming "new" eth0
interface to the next "free" ethX) seems to be flawed.

If I'd were to implement this scheme, I'd do two things
instead of one currently done, and I'd do whatever is
currently done by udev a bit differently (but second
half requires (minor) kernel mods):

first of all, I'd turn this behaviour off by default,
but only when the user asked me to do so - say, when
a new NIC is found, ask a user what's the name he
wants it to be known as.  *Or* choosed different
"basename" for the renamed devices.  So that
in-kernel eth0 becomes, say, nicX instead of
ethX - to make things explicit.  Current way is just
too confusing, when eth0 quietly becomes eth2 or
whatnot.

And second half, which is more important here, is to
always keep kernel names, and create aliases named
by user (or automatic nicX scheme).  This is fundamental --
applies to every device on the system.  For example,
if kernel says it has disk named "sda", it should be
accessible as /dev/sda (and /sys/block/sda, whatever),
and any alternative names ("boot disk", disk-serial-12345
etc yadda) should be symlinks in /dev.  Ie, general rule
is to remove *ALL* "NAME" statements from udev.conf file
and use "SYMLINK" instead.

For network interfaces, ifconfig -a may omit the kernel
names from the listing (but in this case, say, ifconfig -aa
should still show them), or alternatively it may show
something like

eth0      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX  Name nic10
                                                      ...
[ message continues ]

It does not rename ethX to the "next free" one, but to a _persistent_ one.
If it were a "next free" thing, then removing a card would shuffle all
your eth around again (and invalidate your iptables rules at the same

Remember that persistent names also need to provide means for
hot-pluggable devices. Say your eth0 was a wireless, then you surely would
_not ever_ want that on removal of eth0, all other cards step one down
(eth1,eth2,ethN->eth0,eth1,ethN-1). Unfortuantely, I think it is hard (if
not that, then it's a lot of code) to distinguish coldplugged vs

This is easy. Edit /lib/udev/rename_netiface to always hand out "nicX"
regardless of whether the input device was ethX, trX, raX, wlanX or


See above - make rename_netiface use nicX. (Symlinks don't exist for


I prefer nic10 directly over having a dual. You'd be totally lost

(1) The kernel starts with ethX
(2) udev renames it to something else

	Jan
-- 
-

[ message continues ]

Note I said ``"new" eth0'' -- i.e, when udev sees new NIC (with new, yet
unknown to this system, MAC address), it assigns it a "next free" (from
it's persistent names list), now persistent, ethN.

Shuffling rest of the interfaces if eth0 is removed and no this persistent
naming present is obvious, including invalidating iptable rules and
breaking dhcp configuration and other stuff.  But I was referring to

There's really no need to distinguish them (and by the way, wireless !=
hot-pluggable.  There are PCI wireless cards (non-hotplug), and there
are, say, PCMCIA or USB ethernet cards (hotplug)).

Well, I see your point here (I think) -- by assigning names to hotplug
devices from a different namespace (hpethN vs ethN for example) we will
stop shuffling *everything* (without persistent names like udev does) -
but that doesn't really help anyway because of module loading order for
example, and because non-hotplug devices (like PCI) can be missing
(and new added) too on next reboot.

What I mean is -- if I, as a user, care about interface (or other)
names when I replug my NICs (if I ever do that in the first place),
I can assign names to them explicitly (and some programs that are
running at system startup - like kudzu on redhat for example - may
just ask me when finding something new), and THOSE explicitly set
names should be persistent for sure.  Preferrable they will be in
different namespace (not named as ethX but, say, lan or isp or
segment12 - user chooses the name).  And nothing will break
(iptables or dhcp or whatnot) when using THOSE persistent names.

When I don't care, usually I don't have many interfaces to worry
about, either.  But in this case it's expectable that names of
existing interfaces after removing one may change.

Kernel uses SOME names for the interfaces anyway when it boots up
(more on this below).  If - in case I don't care or just didn't
know (which is more often I think) about renumbering, udev by
default MAY assign persistent names like it does ...
[ message continues ]

Generally, the "link is xyz" message comes directly after loading the module,
so it should be eth0 before udev gets a chance to rename it. Or maybe not -
in which case, well, you're literally fubared, and your distro should put a

Oh I think it already has a "primary name" today --

$ readlink /sys/class/net/eth0/device
../../../../../devices/pci0000:00/0000:00:04.0

there is your primary name, and your secondary name is ethZ. :)


	Jan
-- 
-

[ message continues ]

Yes, first message is generated before udev has a chance to act.
And no, I just don't use udev, and I hope very much that it will
not become required (it is slowly becoming - for example, some
packages on Debian (like xen for example) now explicitly depends
on udev - but so far  I managed to satisfy this dependency by

This primary name isn't at all useful - I can't ifconfig or fdisk it,
and it's not shown in log/dmesg either.

/mjt
-

[ message continues ]

udev is not problem - problem si crazy default configuration
of udev used by some distros. If you use udev with simple sane
configuration, then it just creates device nodes based on kernel
names.

--=20
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org, jabber: santiago@=
njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
[ message continues ]

^^^^^^^^^^^^

you mean like this:
eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 45e1.
...
eth2: link up, 100Mbps, full-duplex, lpa 0x45E1


I think it would be helpful.

/herp 
-

[ message continues ]

It is questionable what is _persistent_ . MAC-based names are persistent
with regard to adding and removing of other cards, 'Plain' names are persistent
with regard to replacing that card with different item (of a same kind).

I am very happy that (using 'plain' names) i can send technician to
replace broken NIC in our routers without need for configuration
change.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org, jabber: santiago@njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-

[ message continues ]

this is a very important point, and with the distros (and many kernel 
people) treating udev as a requirement this is going to bite a lot of 
people.

David Lang
-

[ message continues ]

Two notes:

  1. Udev doesn't restrict you to any one naming scheme.  If you want
something else than a MAC based scheme, e.g. a PCI topology based
scheme, udev most certainly can do that for you.  But the kernel can't.

  2. Consider udev a kernel extension in userspace, with the benefit of
configurability and scriptability, features that kernel extensions in
kernelspace can't offer.  Of course this gain of features doesn't come
at zero cost:  You need a minimal userspace environment at boot time.

Quoting myself from http://marc.info/?l=linux-scsi&m=118613786003162:

There is a variety of possible naming schemes:

  - Naming by order of discovery.
  - Naming by vendor/model name strings.
  - Naming by universally unique identifier.
  - Naming by topology.
  - ...

Only the simplest of these schemes (naming by order of discovery) is
hardwired into the kernel portion of the Linux OS.  The other naming
schemes are (or can be) implemented in the userland portion of the Linux OS.

There is only the most primitive naming scheme implemented in the kernel
because naming policy, like most other kinds of policy, is better left
to userland.  The kernel is a too restricted framework to implement such
things.  The kernel lacks runtime-configuration files, scripting
interfaces, et cetera.
-- 
Stefan Richter
-=====-=-=== =--- ---==
http://arcgraph.de/sr/
-

[ message continues ]

I understand the flexibility that this provides, unfortunantly (IMHO) 
default udev rules (or at least what many distros are shipping by default) 
changes from this simple naming scheme in a way that hides the fact from 
the user. This means that many users will not even realize the change in 
policy until the hardware changes and things don't act the way they were 
expected to. In my case it was removing 3 quad cards from a machine and 
finding that there was no eth0 on the box, instead there was a eth12, this 
is fairly benign. what would have caused me significant problems would 
have been having a card fail in a production box, have it replaced and 
then found that the interfaces were now eth4-eth22 instead of eth0-eth18. 
having the interfaces named differently on different boxes with identical 
hardware based on the history of what has been plugged into the boxes in 
the past is not what sysadmins expect.

David Lang
-

[ message continues ]

(which is in most cases also the scheme that's the least useful to

Yes, these rules by far don't fit everyone's needs.  People who often
use hotpluggable NICs are probably served best by MAC address based
naming.  Boxes with field replacable but otherwise fixed NICs apparently
rather need a naming scheme based on PCI/PCIe topology.  (This requires
that the topology is exposed to userspace in comparable manner across
boots and across kernel version updates.)

So, an administrator should get to choose between different well
documented naming schemes.

Also, like Jan mentioned, confusion can already be minimized by renaming
eth[0-9]+ -> net_[a-z]+ (for example, or nic[0-9]+ like Jan wrote)
rather than eth[0-9]+ -> eth[0-9]+.  That way it's clearer at all times
whether the original names or names given by userspace are used.

And there should be a log message when a device was renamed.  Better
yet, like Michal wrote:  In case of device files for mass storage, there
is no _renaming_.  Instead, udev creates _aliases_ (symlinks), and it
does so with a few different naming schemes at once so that admins or
users immediately have a choice:
$ ls /dev/disk/
by-id  by-path  by-uuid

Any chance that there could be aliases to network interfaces?  Aliases
for device files are easy --- they live only in userspace.
-- 
Stefan Richter
-=====-=-=== =--- --=--
http://arcgraph.de/sr/
-

[ message continues ]

the detection order works pretty well, we don't do parallel detection yet, 
and when we do having parallel detection, but serial registration (in a 
defined order) will work.

yes, this can change across kernel version, but in practice it seldom 
does. having run linux on production systems since the 2.0 days (and on 
personal systems since before 0.99) there have only been a handful of 

useing different names for the MAC based names, and providing both names 
at once would work very well.

David Lang
-

[ message continues ]

Wait, you forget that something may change the name. That dmesg message
from 1 second ago does not need to be valid anymore, just as anything
else in this world.



I think it once did with suse, but it does not right now. Worth fixing

So blame your distro for not integrating udev correctly with dhcp-client.
I can only speak for suse, where you define BOOTPROTO=dhcp for an
interface. Then, on /etc/init.d/network, every interface that has a
configuration file gets run, so you never see what ethX udev picked for
the day, but things still work. That's good^TM.


	Jan
-- 
-

[ message continues ]

there are many things in this world which are usually very persistent, and
people rely on their persistence. e.g. in my office, I assume the phone number
is still the same I used 1 second ago ... but what has this to do with
ethernet device names? well: I expected the names persist - like they did
without udev. I'm used that things persist, as probably the rest of the world :-)

cheers,
herp
-

[ message continues ]

Yes, your telephone number persists even if you plug it into another
jack (well, at least for my ISDN box, this holds true). Your names
did persist - no card uses eth0 (which seems to belong to another one
that is not currently installed). Note also that not the names per se
are persistent, the (name,device) tuples are.


	Jan
-- 
-

[ message continues ]

That was my argument - there should be no way to *change* the name, but
to give an alias(es) - entirely different thing.

Yes, if a device is replugged during that one second, it's another
at least "instance" of that device - similar to 'ifindex' field in
interface description (not shown by ifconfig but shown by `ip link'),
or to usb endpoint numbers which gets incremented each time one
plug something in.

But as long as the device is connected, it should have the same
name - that's my key point.  You may change its aliases as you
wish, but not the "primary name".


Again, this is questionable - the integration part, right way to it,
that is.

If - recalling my "naming scheme" with kernel ethX (which may change each
boot or even at runtime, OR may not change at all if I don't replug
devices), and nicN which is based on particular device's MAC address, --
I configured dhcp to listen on eth0, I assume it's the first network
card found by the system, whatever it is.  In this case, if I replaced
the card (because previous one was faulty etc), it will continue to
work (provided no other renames was done) without renames done by
udev, and will break with current udev behaviour.  But if I configured
dhcp to listen on *this* NIC with *this* serial number and MAC address,
current udev behaviour is right - the system just assumes that this
particular card isn't here (yet?) and hence dhcp shouldn't run on it.

You see - we again have two names - "first interface found by kernel"
and "this particular card with this serial number", and both of them
are useful.

Partially this issue can be solved by - say - kudzu asking for a
name if it finds new hardware (we'll answer it with the name our
replaced card had) - but such behaviour is out of the question
because system startup scripts should not generally ask "random
questions".

/mjt
-

[ message continues ]

Ah, in that case, make the kernel print the PCI-ID instead of the name.
(Or perhaps both together.)


As for userspace, you are free to do whatever you find most useful.



	Jan
-- 
-

[ message continues ]

Hey,


I know I have seen my kernel outputting "A renamed to B". Since you two 
however wanted that information in the first place, I grepped a bit 
around, and actually found, (drumroll), that the SUSE kernel has had a 
proper patch for [I can't remember how long] quite some time. (At least 
one distro which does the right thing.) I copied it below.


	Jan
===
Name: patches.suse/nameif-track-rename.patch
Subject: [PATCH] keep track of network interface renaming
From: Olaf Hering <olh@suse.de>

Keep track about which network interface names were renamed after the
network device driver printed its banner. Example insanity:

honeydew:~ # dmesg| grep -Ew '(eth[0-9]|rename|renamed)'
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection
dev_change_name: about to rename 'eth3' to 'eth0'
dev_change_name: about to rename 'eth3' to 'ethxx3'
eth3 renamed to ethxx3
dev_change_name: about to rename 'ethxx3' to 'eth0'
dev_change_name: about to rename 'eth0' to 'eth3'
eth0 renamed to eth3
dev_change_name: about to rename 'eth1' to 'eth2'
dev_change_name: about to rename 'eth1' to 'ethxx1'
eth1 renamed to ethxx1
dev_change_name: about to rename 'ethxx1' to 'eth2'
dev_change_name: about to rename 'eth2' to 'eth1'
eth2 renamed to eth1
dev_change_name: about to rename 'ethxx3' to 'eth0'
ethxx3 renamed to eth0
dev_change_name: about to rename 'ethxx1' to 'eth2'
ethxx1 renamed to eth2
e1000: eth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex



Signed-off-by: Olaf Hering <olh@suse.de>

 net/core/dev.c |    4 ++++
 1 files changed, 4 insertions(+)

--- linux-2.6.21.orig/net/core/dev.c
+++ linux-2.6.21/net/core/dev.c
@@ -822,7 +822,11 @@ int dev_change_name(struct net_device *d
 	else if (__dev_get_by_name(newname))
 		return -EEXIST;
 	else
+	{
+		if (strncmp(newname, ...
[ message continues ]

I just made udev when it successfully renamed an interface to write
that to the kernel log, so dmesg will show:
  <6>udev: renamed network interface eth0 to eth1

Kay
-

[ message continues ]

I think it is helpful to integrate the suse patch rather than to patch udev
alone. This way, renames that do not involve udev also show up.

	Jan
-- 
-

[ message continues ]

But if you need to swap interface names, you will see the useless
temporary device names. On SUSE, nothing else renames network interfaces
these days, so we'll probably just remove that patch. :)

Kay

-

[ message continues ]

Yeah on SUSE on SUSE. The _user_ may very well swap these, either by using
/usr/sbin/ifrename (which is not even from udev!), or doing the magic himself
(ioctls, netlink, whatever is needed).

Also, it may happen that further things pop up during the two renames, e.g.

	eth0 renamed to ethxx0
	ethxx0: link up
	ethxx0 renamed to foo0

If only udev were to print it:

	eth0: RealTek 8139 whatever
	ethxx0: ink up
	eth0 renamed to foo0

and you think "what's ethxx0?".


	Jan
-- 
-

[ message continues ]

hm, well, a thought, maybe udev should report what is doing, like
printinig "renamed eth0 to eth2", or such.

the problem with this device renaming in my case was that other software,
in particular dhcpcd, didnt get any lease, because (obviously?) dhcpcd
on the other hand _still_ seemed to look for eth0, and thus, after
booting, there was no network configured at all.

Maybe the name "eth0" is hardcoded in the gentoo init scripts, I dont know.

Can this be considered a distrubtion bug?

cheers,
herp
-

[ message continues ]

No, not strange at all. At least openSUSE ensures (or TRIES - there
are _really_ broken chips out there that change their MAC every boot)
that each card has the same interface name regardless of load order etc.




	Jan
-- 
-

[ message continues ]