Red Hat Bugzilla – Bug 105826
HWADDR/nameif and continuously cycling device names
Last modified: 2014-03-16 22:39:04 EDT
Description of problem:
My laptop has the following /etc/mactab:
eth0 == builtin PCI 3com 10/100 nic
eth1 == builtin PCMCIA (internal socket 2) Orinoco wireless
eth2 == insertable Cisco Aironet 350 wireless nic
eth3 == insertable Xircom RealPort 10/100 nic
My ifcfg-ethX files all have appropriate HWADDR lines.
Generally, everything seems to work fine (modulo enabling IPv6), however, I
started testing corner cases and found a bug.
Usually my builtin Orinoco is always "inserted". I "ejected" it using the command:
cardctl eject 2
Now I no longer have a 'eth1'. If I then slide in my Xircom into my externally
accesible PCMCIA slot(s) it properly comes up as the desired eth3.
BUT if I insert the Cisco aironet 350, instead of comming up as the desired
eth2, it comes up as "devXXXX" where the "XXXX" is a seemingly random number.
Another strange thing is that if I run "ifconfig" repeatedly, I see different
"XXXX" values each time. It seems to be continuously cycling through different
dev$RANDOM. Fun with bash constructs.
Note that /etc/mactab isn't used at all. Because nameif can't do atomic swapping
of two deadlocking interfaces, listing everything in mactab doesn't help if
things get confused.
Normally what happens here is that there's an unresolvable conflict. What does
'ifconfig -a' say... are there any devices loaded that are failing to be renamed?
As far as I can tell, the HWADDR= functionality has always been broken
in Red Hat Linux due to Bug #75572 . While the example shown in that
bug is wrong, the problem still exists.
Tehcnically, that shouldn't affect this. nameif *does* return 1 on
failures due to name collisions, and the initscripts aren't going to
call nameif on interfaces that don't exist.
Closing bugs on older, no longer supported, releases. Apologies for any lack of
Please try to reproduce this on a current release, such as Fedora Core 4. If the
issue persists, please open a new issue. This particular code has been reworked
a few times since this original report.