kernel 2.6.17: hostap_cs not working, used to work on older kernels

[Bryan Kadzban]

Jar wrote:
> claytonk at 163.com wrote:
> 
>> wlan0_ren Link encap:Ethernet  HWaddr 00:02:6F:34:96:3C BROADCAST
>> MULTICAST  MTU:1500  Metric:1
> 
> 
> This seems to be wlan0 interface, but why it is renamed to wlan0_rem?

Current Debian testing and unstable udev packages (by default anyway)
have config files that generate persistent names for network interfaces.
They're supposed to match by MAC address, although I've heard of some
strangeness if you have multiple devices with the same MAC (as in e.g.
wifi0 and wlan0).  I *think* that's been fixed now, but I'm not sure.

Anyway, when udev sees a NIC added that it has a rename rule for, and
the NIC doesn't already have that name, then it tries to do the rename.
But if the rename fails because a *different* NIC already has that name,
then it renames it to <old name>_ren, waits several seconds (during this
time the appropriate rule for the other interface is supposed to run, to
give *it* a different name), and tries again.  The _ren is there to
allow udev to "swap" names between NICs.

So say you have one MAC configured in udev to be named eth0, and another
MAC configured to be named eth1.  If the second MAC comes up first (and
is given eth0 by the kernel), then udev will attempt to rename it to
eth1, possibly fail (if eth1 already exists), then rename it to eth0_ren
and sleep.  In the meantime, the rule for the first MAC should run, and
name it eth0 (which is no longer in use).  Then the second MAC should
wake up, and the rename from eth0_ren to eth1 should succeed.

It looks like Debian probably created a MAC-based rule for this
interface, and you're seeing the intermediate step where it's in the
middle of being renamed.  Or, you're seeing it get hung up somehow
(perhaps it's trying to rename wlan0 to wifi0, which will never go away?).

Look into your /etc/udev/rules.d directory to see if you can find a
rules file whose name contains persistent-net (but not
persistent-net-generator).  If you modify that file to be more specific
(i.e. not match wlan0; how you do this is up to you), that *should* fix
the name.

These persistent net rules may also explain why the Orinoco driver is
using a wifi0 or wlan0 interface name.  Since it's the same MAC, udev
will apply the rule that was generated by the hostap driver (which gave
the interface the wifi0 or wlan0 name).  So you won't see it as ethX
unless you edit that same rules file to change the rule.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20061022/258c8b80/attachment.pgp