On Tue, Dec 8, 2009 at 10:43 AM, Stephen Hemminger <shemminger@xxxxxxxxxx> wrote: > On Tue, 8 Dec 2009 09:29:40 -0500 > "John W. Linville" <linville@xxxxxxxxxxxxx> wrote: > >> On Mon, Dec 07, 2009 at 05:26:16PM -0800, Stephen Hemminger wrote: >> > The default udev persistent network rules based on hardware mac id doesn't >> > work well when multiple SSID's are created on an access-point. The command >> > iw phy phy0 interface add wlan1 type managed >> > >> > is supposed to make a device name wlan1, but udev sees that it has the same >> > mac address as wlan0 and gets confused leaving the device named wlan1_rename >> > >> > It looks like wlanX is breaking assumptions of existing udev persistent network >> > device name generation rules. Perhaps there needs to be special case for wlanX >> > devices? >> >> Yes, probably so. But what would it be? Factoring-in SSID is clearly >> not right for the usual case (i.e. one interface on a mobile device). >> I'm not sure what else one could use as a key. >> >> What does udev do for bridge, bond, or vlan devices? Don't those >> share MAC addresses with the underlying physical device? >> >> John > > At least on ubuntu/debian the name whitelist is: > > > # device name whitelist > KERNEL!="eth*|ath*|wlan*[0-9]|msh*|ra*|sta*|ctc*|lcs*|hsi*", GOTO="persistent_net_generator_end" > > So bond or bridge don't match and don't get tampered with. > > The problem is that wlan* device names are used for both hardware and virtual > devices. Udev scripts can be fixed "do the right thing" but there is not sufficient > information for the script to decide how to attach persistent name. > What values from sysfs (ie attributes) should script be using? This probably > means that additional attributes needed to be added to wireless device infrastructure > in kernel. We could likely use the new SET_NETDEV_DEVTYPE() but I have yet to see where this is exported. It must be there somewhere. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
