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 00:08:74:46:26:9D eth1 00:02:2D:6C:97:4E eth2 00:0B:FD:C6:4C:AD eth3 00:10:A4:E1:52:8A Details: 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 numbers.
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 response. 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.