Red Hat Bugzilla – Bug 85938
PCMCIA/wireless-tools ignore HWADDR settings when choosing network interface name
Last modified: 2014-03-16 22:35:02 EDT
Description of problem:
When the PCMCIA subsystem initializes my wireless card it automatically assigns
it the next available interface name, regardless whether or not the card has
been bound to a specific interface name by the HWADDR parameter in
Version-Release number of selected component (if applicable):
Redhat 8.0 with all updates (as of 2003-03-10).
How reproducible: Always happens.
Steps to Reproduce:
1. Configure a network script that will not be the next one available when your
wireless card is inserted (f.e. ifcfg-eth2 on my system when my laptop is
undocked) with the HWADDR address parameter, and make the value of that
parameter be the hardware address of your wireless card.
2. Insert your wireless card.
Actual results: Your wireless card is assigned the next available network
Expected results: Your wireless card is assigned the interface name you configured.
... says, "When an ethernet card is detected, it will be assigned the first free
interface name, which will normally be eth0," so maybe this is a PCMCIA problem.
Note that the interface name <-> driver mappings in /etc/modules.conf are also
ignored, leading to mismatches between the driver which is supposed to be loaded
for an interface and the one which is actually loaded. Among other things, this
causes neat to complain when it is run while the wireless card is in the wrong slot.
The reason this bug matters is that the network cards available on a laptop can
vary regularly, f.e., my laptop has a built-in ethernet card which is always
available and a card in its dock at work which is only available while I'm at my
desk at work. This bug forces me to reconfigure my system every time I move
between my desk at work and any other location (home, a conference room at work,
etc.). The only workaround I have found is to hack my boot and wakeup scripts
to initialize PCMCIA first (so my wireless card always gets eth0), but that's
hacky and error-prone.
Fixed in 7.26-1.