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
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Wed, 2009-12-09 at 06:54 +0300, Andrey Borzenkov wrote:
> Is it possible to distinguish between automatic system enumeration when
> new device is created and explicit name that user gives? Because in
> example above (iw phy add interface) user already supplied specific
> name; there is no reason for udev to (try to) mangle it.
>
> So far the only possibility seems to check for wild card in interface
> name. So what about adding new event attribute NAME_AUTOGENERATED=(yes|
> no) and simply leaving any event with NAME_AUTOGENERATED=no alone in
> udev? Any immediate problems?
This is non-trivial because it really goes through the same code paths
internally. Feel free to send patches.
johannes
On Tue, 8 Dec 2009 09:29:40 -0500
"John W. Linville" <[email protected]> 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.
Hi Luis,
> >> > 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.
they are part of the uevent the kernel sends. It will have the DEVTYPE
value there. However this has to be exactly the hardware type and in
both cases it will be "wlan" and has to be. The analogy that works here
is similar to partitions and disks in the storage world. We have just
different kinds of network interfaces.
Regards
Marcel
On Wed, Dec 09, 2009 at 06:54:27AM +0300, Andrey Borzenkov wrote:
> On Tuesday 08 of December 2009 23:05:04 John W. Linville wrote:
> > On Tue, Dec 08, 2009 at 08:29:11PM +0100, Johannes Berg wrote:
> > > On Tue, 2009-12-08 at 13:52 -0500, John W. Linville wrote:
> > > > So, probably we need to map from the wlanX name to the phyY name,
> > > > then determine whether or not this is the first wlanX for phyY.
> > > > If not, then the name should be left alone.
> > > >
> > > > Now, how do we figure out how many wlanX's belong to phyY?
> > >
> > > And what's the "first" one? :)
> >
> > I suppose I was figuring that if there was only one, it was the
> > first. :-) But you're right, I suppose that could be racy...
> >
> > > ls /sys/class/net/wlan0/device/net/
> > >
> > > will give you the list of interface associated with this device.
> >
> > Cool...
> >
>
> Is it possible to distinguish between automatic system enumeration when
> new device is created and explicit name that user gives? Because in
> example above (iw phy add interface) user already supplied specific
> name; there is no reason for udev to (try to) mangle it.
That's why I wanted the "first" one...it is auto-generated. :-)
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Tuesday 08 of December 2009 23:05:04 John W. Linville wrote:
> On Tue, Dec 08, 2009 at 08:29:11PM +0100, Johannes Berg wrote:
> > On Tue, 2009-12-08 at 13:52 -0500, John W. Linville wrote:
> > > So, probably we need to map from the wlanX name to the phyY name,
> > > then determine whether or not this is the first wlanX for phyY.
> > > If not, then the name should be left alone.
> > >
> > > Now, how do we figure out how many wlanX's belong to phyY?
> >
> > And what's the "first" one? :)
>
> I suppose I was figuring that if there was only one, it was the
> first. :-) But you're right, I suppose that could be racy...
>
> > ls /sys/class/net/wlan0/device/net/
> >
> > will give you the list of interface associated with this device.
>
> Cool...
>
Is it possible to distinguish between automatic system enumeration when
new device is created and explicit name that user gives? Because in
example above (iw phy add interface) user already supplied specific
name; there is no reason for udev to (try to) mangle it.
So far the only possibility seems to check for wild card in interface
name. So what about adding new event attribute NAME_AUTOGENERATED=(yes|
no) and simply leaving any event with NAME_AUTOGENERATED=no alone in
udev? Any immediate problems?
On Tue, 2009-12-08 at 13:52 -0500, John W. Linville wrote:
> So, probably we need to map from the wlanX name to the phyY name,
> then determine whether or not this is the first wlanX for phyY.
> If not, then the name should be left alone.
>
> Now, how do we figure out how many wlanX's belong to phyY?
And what's the "first" one? :)
ls /sys/class/net/wlan0/device/net/
will give you the list of interface associated with this device.
johannes
On Tue, Dec 08, 2009 at 08:29:11PM +0100, Johannes Berg wrote:
> On Tue, 2009-12-08 at 13:52 -0500, John W. Linville wrote:
>
> > So, probably we need to map from the wlanX name to the phyY name,
> > then determine whether or not this is the first wlanX for phyY.
> > If not, then the name should be left alone.
> >
> > Now, how do we figure out how many wlanX's belong to phyY?
>
> And what's the "first" one? :)
I suppose I was figuring that if there was only one, it was the
first. :-) But you're right, I suppose that could be racy...
> ls /sys/class/net/wlan0/device/net/
>
> will give you the list of interface associated with this device.
Cool...
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Tue, Dec 08, 2009 at 10:43:36AM -0800, Stephen Hemminger wrote:
> On Tue, 8 Dec 2009 09:29:40 -0500
> "John W. Linville" <[email protected]> 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.
So, probably we need to map from the wlanX name to the phyY name,
then determine whether or not this is the first wlanX for phyY.
If not, then the name should be left alone.
Now, how do we figure out how many wlanX's belong to phyY?
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Tue, 8 Dec 2009 10:50:30 -0800
"Luis R. Rodriguez" <[email protected]> wrote:
> On Tue, Dec 8, 2009 at 10:43 AM, Stephen Hemminger
> <[email protected]> wrote:
> > On Tue, 8 Dec 2009 09:29:40 -0500
> > "John W. Linville" <[email protected]> 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.
Both devices would have same type? don't see how that would help
Imagine a system with two Atheros cards, and 2 SSID's per card.
How would devices be identified by udev to assign persistent name?
On Tue, Dec 8, 2009 at 10:59 AM, Stephen Hemminger
<[email protected]> wrote:
> On Tue, 8 Dec 2009 10:50:30 -0800
> "Luis R. Rodriguez" <[email protected]> wrote:
>
>> On Tue, Dec 8, 2009 at 10:43 AM, Stephen Hemminger
>> <[email protected]> wrote:
>> > On Tue, 8 Dec 2009 09:29:40 -0500
>> > "John W. Linville" <[email protected]> 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.
>
> Both devices would have same type? don't see how that would help
>
> Imagine a system with two Atheros cards, and 2 SSID's per card.
> How would devices be identified by udev to assign persistent name?
Yeah sorry, I was thinking of just wlan0++ for a new wlan net device
type, but yeah keeping them persistent would require more work.
Luis
On Tue, Dec 8, 2009 at 10:43 AM, Stephen Hemminger
<[email protected]> wrote:
> On Tue, 8 Dec 2009 09:29:40 -0500
> "John W. Linville" <[email protected]> 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
On Dec 08, "John W. Linville" <[email protected]> wrote:
> What does udev do for bridge, bond, or vlan devices? Don't those
> share MAC addresses with the underlying physical device?
They are blacklisted (by the DRIVERS=="?*" check) so they do not get
persistent names.
--
ciao,
Marco