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

[claytonk at 163.com]

On Sun, 22 Oct 2006 15:24:33 -0400
Bryan Kadzban <bryan at kadzban.is-a-geek.net> wrote:

> 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.

/etc/udev/rules.d/z25_persistent-net.rules does have an entry corresponding to my card:

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:02:6f:34:96:3c", NAME="eth1"

however if I was to tweak this file it is not clear to me how I would take care of the case where there are two interfaces with exactly the same MAC.

> 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.

I just wanted to close the loop on this old thread: I think udev has definitely gotten hung-up in the (persistent) renaming process, and is stuck at an intermediate point that does not work. ie. this is the final permanent state of udev's efforts to configure the interface:

eth1      Link encap:UNSPEC  HWaddr 
00-02-6F-34-96-3C-30-3A-00-00-00-00-00-00-00-00
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:3 Base address:0x100

wlan0_ren Link encap:Ethernet  HWaddr 
00:02:6F:34:96:3C
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:3 Base address:0x100

If it is fixed, the fix hasn't made it to unstable yet, and theoretically this should make hostap_cs unuseable on any Debian testing or unstable environment. I sent a bug report:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397328

Clayton