Originally by Johannes Berg. This patch adds support for devices that do not
report their MAC address until the firmware is loaded. While the address is not
known, a multicast on is used.
Signed-off-by: Luis Carlos Cobo <[email protected]>
Tested-by: Javier Cardona <[email protected]>
---
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/main.c | 61 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c916c2f..8e8c0eb 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -551,6 +551,7 @@ struct ieee80211_local {
const struct ieee80211_ops *ops;
struct net_device *mdev; /* wmaster# - "master" 802.11 device */
+ unsigned int hwid;
int open_count;
int monitors, cooked_mntrs;
/* number of interfaces with corresponding FIF_ flags */
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index cf477ad..2204aa5 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -178,6 +178,20 @@ static inline int identical_mac_addr_allowed(int type1, int type2)
type2 == IEEE80211_IF_TYPE_VLAN)));
}
+static void calculate_invalid_mac(u8 *addr, unsigned int hwid)
+{
+ /*
+ * Random multicast, private use address with hwid mixed in.
+ * Must be multicast to let is_valid_ether_addr() fail on it.
+ */
+ addr[0] = 0xe7;
+ addr[1] = 0xc4;
+ addr[2] = 0x2e ^ ((hwid >> 24) & 0xFF);
+ addr[3] = 0xdd ^ ((hwid >> 16) & 0xFF);
+ addr[4] = 0xcb ^ ((hwid >> 8) & 0xFF);
+ addr[5] = 0x8c ^ ((hwid >> 0) & 0xFF);
+}
+
static int ieee80211_open(struct net_device *dev)
{
struct ieee80211_sub_if_data *sdata, *nsdata;
@@ -187,9 +201,17 @@ static int ieee80211_open(struct net_device *dev)
u32 changed = 0;
int res;
bool need_hw_reconfig = 0;
+ u8 inval_addr[ETH_ALEN];
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ calculate_invalid_mac(inval_addr, local->hwid);
+
+ /* fail early if user set an invalid address */
+ if (compare_ether_addr(dev->dev_addr, inval_addr) &&
+ !is_valid_ether_addr(dev->dev_addr))
+ return -EADDRNOTAVAIL;
+
/* we hold the RTNL here so can safely walk the list */
list_for_each_entry(nsdata, &local->interfaces, list) {
struct net_device *ndev = nsdata->dev;
@@ -288,6 +310,32 @@ static int ieee80211_open(struct net_device *dev)
ieee80211_led_radio(local, local->hw.conf.radio_enabled);
}
+ /*
+ * Check all interfaces and copy the hopefully now-present
+ * MAC address to those that have the special invalid one.
+ */
+ list_for_each_entry(nsdata, &local->interfaces, list) {
+ struct net_device *ndev = nsdata->dev;
+
+ /*
+ * No need to check netif_running since we do not allow
+ * it to start up with this invalid address.
+ */
+ if (compare_ether_addr(inval_addr, ndev->dev_addr) == 0)
+ memcpy(ndev->dev_addr,
+ local->hw.wiphy->perm_addr,
+ ETH_ALEN);
+ }
+
+ /*
+ * Validate the MAC address for this device.
+ */
+ if (!is_valid_ether_addr(dev->dev_addr)) {
+ if (!local->open_count && local->ops->stop)
+ local->ops->stop(local_to_hw(local));
+ return -EADDRNOTAVAIL;
+ }
+
switch (sdata->vif.type) {
case IEEE80211_IF_TYPE_VLAN:
list_add(&sdata->u.vlan.list, &sdata->u.vlan.ap->u.ap.vlans);
@@ -995,6 +1043,8 @@ void ieee80211_if_setup(struct net_device *dev)
dev->open = ieee80211_open;
dev->stop = ieee80211_stop;
dev->destructor = ieee80211_if_free;
+ /* we will validate the address ourselves in ->open */
+ dev->validate_addr = NULL;
}
/* everything else */
@@ -1571,6 +1621,8 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
struct ieee80211_local *local;
int priv_size;
struct wiphy *wiphy;
+ static atomic_t hw_counter = ATOMIC_INIT(0);
+ u8 inval_addr[ETH_ALEN];
/* Ensure 32-byte alignment of our private data and hw private data.
* We use the wiphy priv data for both our ieee80211_local and for
@@ -1601,6 +1653,15 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
local = wiphy_priv(wiphy);
local->hw.wiphy = wiphy;
+ /*
+ * Hack for devices that cannot read the mac address until they are
+ * started... keep an invalid multicast address as the device MAC...
+ * Read on in ieee80211_open().
+ */
+ local->hwid = atomic_inc_return(&hw_counter);
+ calculate_invalid_mac(inval_addr, local->hwid);
+ memcpy(local->hw.wiphy->perm_addr, inval_addr, ETH_ALEN);
+
local->hw.priv = (char *)local +
((sizeof(struct ieee80211_local) +
NETDEV_ALIGN_CONST) & ~NETDEV_ALIGN_CONST);
--
1.5.4.3
On Mon, 2008-07-28 at 16:00 +0200, Michael Buesch wrote:
> On Monday 28 July 2008 15:56:37 Luis Carlos Cobo wrote:
> > On Mon, 2008-07-28 at 15:44 +0200, Michael Buesch wrote:
> > > Well, I think that really is pretty weird and it is confusing to the
> > > user to see that pseudo random MAC that changes suddenly when the device is
> > > initialized. For the human user (so everybody but me), it would be better
> > > to have the MAC all-zeros until the firmware loaded. So it would be obvious
> > > that the MAC is not set, yet. I think userspace
> >
> > The problem is that all-zeroes is actually a valid mac address, owned by
> > Xerox (http://standards.ieee.org/regauth/oui/oui.txt) Not that it will
> > probably cause us any problem, but a multicast address is afaik an
> > invalid mac for a device. Should we go for 01:allzeros?
>
> If that's really a problem, yes. 01:00:00:00:00:00 is still better
> than a pseudo random MAC, IMO. It's immediately obvious to the user
> that the MAC currently is not set.
How about 44:44:44:44:44:44 like orinoco uses for bogus BSSID? If we
can, let's not keep creating yet more bogus MAC addresses.
Dan
So I see three options:
1) Use 00:... and be happy. No problem with udev, we use an address that
is actually valid.
2) Use 01:00... and fix udev so it ignores it.
3) Use 44:44..., because it is what orinoco used and fix udev so it
ignores it.
I would go for solution 2, 00:00:00:00:00:00 is a valid address for a
device and multicast addresses are not, and that should be reflected on
udev's policy.
About persistent names, can we get a persistent name after the device
gets its MAC address? Before that, the device is not being used and it
does not matter much.
--
Luis Carlos Cobo Rus GnuPG ID: 44019B60
cozybit Inc.
On Mon, 2008-07-28 at 15:44 +0200, Michael Buesch wrote:
> On Monday 28 July 2008 15:23:53 Johannes Berg wrote:
> > On Sun, 2008-07-27 at 11:22 -0400, Dan Williams wrote:
> > > On Thu, 2008-07-10 at 16:57 +0200, Luis Carlos Cobo wrote:
> > > > Originally by Johannes Berg. This patch adds support for devices that do not
> > > > report their MAC address until the firmware is loaded. While the address is not
> > > > known, a multicast on is used.
> > >
> > > Johannes, thoughts on this? Is there a better way to do it for devices
> > > that don't know their MAC address until firmware load?
> >
> > I actually wrote this patch, but largely I don't care. It seemed that
> > having unique MAC addresses would screw up less with udev, but maybe we
> > can just leave it zeroed until we know?
>
> Well, I think that really is pretty weird and it is confusing to the
> user to see that pseudo random MAC that changes suddenly when the device is
> initialized. For the human user (so everybody but me), it would be better
> to have the MAC all-zeros until the firmware loaded. So it would be obvious
> that the MAC is not set, yet. I think userspace
> tools should just be fixed, if they have problems with that.
Agreed.
> (What are the udev problems, btw?)
People seem to want persistent device names. Since the kernel doesn't
provide stable device/bus enumeration, there are udev hacks (see
attached from Fedora 9) that read the MAC address of the card on
hot-plug and then assign it to a cached device name so that every time I
plug in my Netgear MA401 it gets "eth2".
Same thing as putting UUIDs on partitions and in /etc/fstab to make sure
your internal SATA drive is always sda no matter what USB stuff you plug
in.
The question is, when the MAC address gets updated, whether udev will
recognize that change and re-name the device to the cached value.
Dan
On Mon, Jul 28, 2008 at 5:25 PM, Michael Buesch <[email protected]> wrote:
> On Monday 28 July 2008 15:57:45 Dan Williams wrote:
>> > (What are the udev problems, btw?)
>>
>> People seem to want persistent device names. Since the kernel doesn't
>> provide stable device/bus enumeration, there are udev hacks (see
>> attached from Fedora 9) that read the MAC address of the card on
>> hot-plug and then assign it to a cached device name so that every time I
>> plug in my Netgear MA401 it gets "eth2".
>
> Yeah well. But using a pseudo-random MAC as a base to build a persistent
> naming scheme on sounds pretty fragile to me. ;)
>
> I think cards that don't supply MAC early simply cannot support
> a really working persistent naming scheme well. udev should probably
> just enumerate eth0 - ethX as it sees the devices. That's as good
> as mixing a numbering scheme into a pseudo MAC, IMO. And it's
> less confusing and it pushes a lot of policy decisions into userspace.
Can devices supply something depending on its bus numbering that will
not change unless it's plugged out.
Just a thought.
Tomas
On Monday 28 July 2008 15:56:37 Luis Carlos Cobo wrote:
> On Mon, 2008-07-28 at 15:44 +0200, Michael Buesch wrote:
> > Well, I think that really is pretty weird and it is confusing to the
> > user to see that pseudo random MAC that changes suddenly when the device is
> > initialized. For the human user (so everybody but me), it would be better
> > to have the MAC all-zeros until the firmware loaded. So it would be obvious
> > that the MAC is not set, yet. I think userspace
>
> The problem is that all-zeroes is actually a valid mac address, owned by
> Xerox (http://standards.ieee.org/regauth/oui/oui.txt) Not that it will
> probably cause us any problem, but a multicast address is afaik an
> invalid mac for a device. Should we go for 01:allzeros?
If that's really a problem, yes. 01:00:00:00:00:00 is still better
than a pseudo random MAC, IMO. It's immediately obvious to the user
that the MAC currently is not set.
--
Greetings Michael.
On Mon, Jul 28, 2008 at 6:14 PM, Dan Williams <[email protected]> wrote:
> On Mon, 2008-07-28 at 17:07 +0200, Johannes Berg wrote:
>> On Mon, 2008-07-28 at 10:59 -0400, Dan Williams wrote:
>>
>> > > If that's really a problem, yes. 01:00:00:00:00:00 is still better
>> > > than a pseudo random MAC, IMO. It's immediately obvious to the user
>> > > that the MAC currently is not set.
>> >
>> > How about 44:44:44:44:44:44 like orinoco uses for bogus BSSID? If we
>> > can, let's not keep creating yet more bogus MAC addresses.
>>
>> Either way, the problem is that these will confuse udev if you have two
>> at the same time, no?
>
> the udev script I attached from Fedora 9 already ignores devices with
> 00:00:00::: so I don't think we'd have a problem with that. Screw the
> Xerox thing, all zeros is just bogus and tons of stuff treats it that
> way already.
So this won't conflict even if you have two or more devices that
claims zero mac address?
Tomas
On Mon, 2008-07-28 at 17:44 +0300, Tomas Winkler wrote:
> On Mon, Jul 28, 2008 at 5:25 PM, Michael Buesch <[email protected]> wrote:
> > On Monday 28 July 2008 15:57:45 Dan Williams wrote:
> >> > (What are the udev problems, btw?)
> >>
> >> People seem to want persistent device names. Since the kernel doesn't
> >> provide stable device/bus enumeration, there are udev hacks (see
> >> attached from Fedora 9) that read the MAC address of the card on
> >> hot-plug and then assign it to a cached device name so that every time I
> >> plug in my Netgear MA401 it gets "eth2".
> >
> > Yeah well. But using a pseudo-random MAC as a base to build a persistent
> > naming scheme on sounds pretty fragile to me. ;)
> >
> > I think cards that don't supply MAC early simply cannot support
> > a really working persistent naming scheme well. udev should probably
> > just enumerate eth0 - ethX as it sees the devices. That's as good
> > as mixing a numbering scheme into a pseudo MAC, IMO. And it's
> > less confusing and it pushes a lot of policy decisions into userspace.
>
> Can devices supply something depending on its bus numbering that will
> not change unless it's plugged out.
No, because it's precisely the bus numbering that the kernel might
change on you. You're not guaranteed persistent device enumeration in
the kernel, and the only thing you could rely on is some sort of UUID of
the hardware itself, which in the case of network devices is the MAC
address. If you have no MAC address then you don't get a persistent
name.
Dan
On Monday 28 July 2008 15:23:53 Johannes Berg wrote:
> On Sun, 2008-07-27 at 11:22 -0400, Dan Williams wrote:
> > On Thu, 2008-07-10 at 16:57 +0200, Luis Carlos Cobo wrote:
> > > Originally by Johannes Berg. This patch adds support for devices that do not
> > > report their MAC address until the firmware is loaded. While the address is not
> > > known, a multicast on is used.
> >
> > Johannes, thoughts on this? Is there a better way to do it for devices
> > that don't know their MAC address until firmware load?
>
> I actually wrote this patch, but largely I don't care. It seemed that
> having unique MAC addresses would screw up less with udev, but maybe we
> can just leave it zeroed until we know?
Well, I think that really is pretty weird and it is confusing to the
user to see that pseudo random MAC that changes suddenly when the device is
initialized. For the human user (so everybody but me), it would be better
to have the MAC all-zeros until the firmware loaded. So it would be obvious
that the MAC is not set, yet. I think userspace
tools should just be fixed, if they have problems with that.
(What are the udev problems, btw?)
--
Greetings Michael.
On Monday 28 July 2008 15:57:45 Dan Williams wrote:
> > (What are the udev problems, btw?)
>
> People seem to want persistent device names. Since the kernel doesn't
> provide stable device/bus enumeration, there are udev hacks (see
> attached from Fedora 9) that read the MAC address of the card on
> hot-plug and then assign it to a cached device name so that every time I
> plug in my Netgear MA401 it gets "eth2".
Yeah well. But using a pseudo-random MAC as a base to build a persistent
naming scheme on sounds pretty fragile to me. ;)
I think cards that don't supply MAC early simply cannot support
a really working persistent naming scheme well. udev should probably
just enumerate eth0 - ethX as it sees the devices. That's as good
as mixing a numbering scheme into a pseudo MAC, IMO. And it's
less confusing and it pushes a lot of policy decisions into userspace.
--
Greetings Michael.
On Wed, Jul 30, 2008 at 07:35:21AM -0400, Dan Williams wrote:
> On Wed, 2008-07-30 at 13:17 +0200, Luis Carlos Cobo wrote:
> > So I see three options:
> >
> > 1) Use 00:... and be happy. No problem with udev, we use an address that
> > is actually valid.
> >
> > 2) Use 01:00... and fix udev so it ignores it.
> >
> > 3) Use 44:44..., because it is what orinoco used and fix udev so it
> > ignores it.
> >
> > I would go for solution 2, 00:00:00:00:00:00 is a valid address for a
> > device and multicast addresses are not, and that should be reflected on
> > udev's policy.
>
> I guess, but having a zero MAC seems more logical to me, and it's also
> the failure case if something doesn't get properly initialized. WEXT
> uses it for "disassociated". We already check for the zero MAC in a
> number of places.
I'm with Dan -- use all zeroes.
John
--
John W. Linville
[email protected]
On Wed, 2008-07-30 at 13:17 +0200, Luis Carlos Cobo wrote:
> So I see three options:
>
> 1) Use 00:... and be happy. No problem with udev, we use an address that
> is actually valid.
>
> 2) Use 01:00... and fix udev so it ignores it.
>
> 3) Use 44:44..., because it is what orinoco used and fix udev so it
> ignores it.
>
> I would go for solution 2, 00:00:00:00:00:00 is a valid address for a
> device and multicast addresses are not, and that should be reflected on
> udev's policy.
I guess, but having a zero MAC seems more logical to me, and it's also
the failure case if something doesn't get properly initialized. WEXT
uses it for "disassociated". We already check for the zero MAC in a
number of places.
But in the end, doesn't really matter to me.
> About persistent names, can we get a persistent name after the device
> gets its MAC address? Before that, the device is not being used and it
> does not matter much.
Yes, if the udev bits are good enough. Just need something unique, and
for net devices, the MAC is supposed to be unique, of course.
Dan
On Thu, 2008-07-10 at 16:57 +0200, Luis Carlos Cobo wrote:
> Originally by Johannes Berg. This patch adds support for devices that do not
> report their MAC address until the firmware is loaded. While the address is not
> known, a multicast on is used.
Johannes, thoughts on this? Is there a better way to do it for devices
that don't know their MAC address until firmware load?
Dan
> Signed-off-by: Luis Carlos Cobo <[email protected]>
> Tested-by: Javier Cardona <[email protected]>
> ---
> net/mac80211/ieee80211_i.h | 1 +
> net/mac80211/main.c | 61 ++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 62 insertions(+), 0 deletions(-)
>
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index c916c2f..8e8c0eb 100644
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -551,6 +551,7 @@ struct ieee80211_local {
> const struct ieee80211_ops *ops;
>
> struct net_device *mdev; /* wmaster# - "master" 802.11 device */
> + unsigned int hwid;
> int open_count;
> int monitors, cooked_mntrs;
> /* number of interfaces with corresponding FIF_ flags */
> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> index cf477ad..2204aa5 100644
> --- a/net/mac80211/main.c
> +++ b/net/mac80211/main.c
> @@ -178,6 +178,20 @@ static inline int identical_mac_addr_allowed(int type1, int type2)
> type2 == IEEE80211_IF_TYPE_VLAN)));
> }
>
> +static void calculate_invalid_mac(u8 *addr, unsigned int hwid)
> +{
> + /*
> + * Random multicast, private use address with hwid mixed in.
> + * Must be multicast to let is_valid_ether_addr() fail on it.
> + */
> + addr[0] = 0xe7;
> + addr[1] = 0xc4;
> + addr[2] = 0x2e ^ ((hwid >> 24) & 0xFF);
> + addr[3] = 0xdd ^ ((hwid >> 16) & 0xFF);
> + addr[4] = 0xcb ^ ((hwid >> 8) & 0xFF);
> + addr[5] = 0x8c ^ ((hwid >> 0) & 0xFF);
> +}
> +
> static int ieee80211_open(struct net_device *dev)
> {
> struct ieee80211_sub_if_data *sdata, *nsdata;
> @@ -187,9 +201,17 @@ static int ieee80211_open(struct net_device *dev)
> u32 changed = 0;
> int res;
> bool need_hw_reconfig = 0;
> + u8 inval_addr[ETH_ALEN];
>
> sdata = IEEE80211_DEV_TO_SUB_IF(dev);
>
> + calculate_invalid_mac(inval_addr, local->hwid);
> +
> + /* fail early if user set an invalid address */
> + if (compare_ether_addr(dev->dev_addr, inval_addr) &&
> + !is_valid_ether_addr(dev->dev_addr))
> + return -EADDRNOTAVAIL;
> +
> /* we hold the RTNL here so can safely walk the list */
> list_for_each_entry(nsdata, &local->interfaces, list) {
> struct net_device *ndev = nsdata->dev;
> @@ -288,6 +310,32 @@ static int ieee80211_open(struct net_device *dev)
> ieee80211_led_radio(local, local->hw.conf.radio_enabled);
> }
>
> + /*
> + * Check all interfaces and copy the hopefully now-present
> + * MAC address to those that have the special invalid one.
> + */
> + list_for_each_entry(nsdata, &local->interfaces, list) {
> + struct net_device *ndev = nsdata->dev;
> +
> + /*
> + * No need to check netif_running since we do not allow
> + * it to start up with this invalid address.
> + */
> + if (compare_ether_addr(inval_addr, ndev->dev_addr) == 0)
> + memcpy(ndev->dev_addr,
> + local->hw.wiphy->perm_addr,
> + ETH_ALEN);
> + }
> +
> + /*
> + * Validate the MAC address for this device.
> + */
> + if (!is_valid_ether_addr(dev->dev_addr)) {
> + if (!local->open_count && local->ops->stop)
> + local->ops->stop(local_to_hw(local));
> + return -EADDRNOTAVAIL;
> + }
> +
> switch (sdata->vif.type) {
> case IEEE80211_IF_TYPE_VLAN:
> list_add(&sdata->u.vlan.list, &sdata->u.vlan.ap->u.ap.vlans);
> @@ -995,6 +1043,8 @@ void ieee80211_if_setup(struct net_device *dev)
> dev->open = ieee80211_open;
> dev->stop = ieee80211_stop;
> dev->destructor = ieee80211_if_free;
> + /* we will validate the address ourselves in ->open */
> + dev->validate_addr = NULL;
> }
>
> /* everything else */
> @@ -1571,6 +1621,8 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
> struct ieee80211_local *local;
> int priv_size;
> struct wiphy *wiphy;
> + static atomic_t hw_counter = ATOMIC_INIT(0);
> + u8 inval_addr[ETH_ALEN];
>
> /* Ensure 32-byte alignment of our private data and hw private data.
> * We use the wiphy priv data for both our ieee80211_local and for
> @@ -1601,6 +1653,15 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
> local = wiphy_priv(wiphy);
> local->hw.wiphy = wiphy;
>
> + /*
> + * Hack for devices that cannot read the mac address until they are
> + * started... keep an invalid multicast address as the device MAC...
> + * Read on in ieee80211_open().
> + */
> + local->hwid = atomic_inc_return(&hw_counter);
> + calculate_invalid_mac(inval_addr, local->hwid);
> + memcpy(local->hw.wiphy->perm_addr, inval_addr, ETH_ALEN);
> +
> local->hw.priv = (char *)local +
> ((sizeof(struct ieee80211_local) +
> NETDEV_ALIGN_CONST) & ~NETDEV_ALIGN_CONST);
On Mon, 2008-07-28 at 17:07 +0200, Johannes Berg wrote:
> On Mon, 2008-07-28 at 10:59 -0400, Dan Williams wrote:
>
> > > If that's really a problem, yes. 01:00:00:00:00:00 is still better
> > > than a pseudo random MAC, IMO. It's immediately obvious to the user
> > > that the MAC currently is not set.
> >
> > How about 44:44:44:44:44:44 like orinoco uses for bogus BSSID? If we
> > can, let's not keep creating yet more bogus MAC addresses.
>
> Either way, the problem is that these will confuse udev if you have two
> at the same time, no?
the udev script I attached from Fedora 9 already ignores devices with
00:00:00::: so I don't think we'd have a problem with that. Screw the
Xerox thing, all zeros is just bogus and tons of stuff treats it that
way already.
Dan
On Sun, 2008-07-27 at 11:22 -0400, Dan Williams wrote:
> On Thu, 2008-07-10 at 16:57 +0200, Luis Carlos Cobo wrote:
> > Originally by Johannes Berg. This patch adds support for devices that do not
> > report their MAC address until the firmware is loaded. While the address is not
> > known, a multicast on is used.
>
> Johannes, thoughts on this? Is there a better way to do it for devices
> that don't know their MAC address until firmware load?
I actually wrote this patch, but largely I don't care. It seemed that
having unique MAC addresses would screw up less with udev, but maybe we
can just leave it zeroed until we know?
johannes
On Wed, 2008-07-30 at 10:30 -0400, John W. Linville wrote:
> I'm with Dan -- use all zeroes.
It looks like most people prefer all zeroes, I'll go for that.
--
Luis Carlos Cobo Rus GnuPG ID: 44019B60
cozybit Inc.
On Mon, 2008-07-28 at 15:44 +0200, Michael Buesch wrote:
> Well, I think that really is pretty weird and it is confusing to the
> user to see that pseudo random MAC that changes suddenly when the device is
> initialized. For the human user (so everybody but me), it would be better
> to have the MAC all-zeros until the firmware loaded. So it would be obvious
> that the MAC is not set, yet. I think userspace
The problem is that all-zeroes is actually a valid mac address, owned by
Xerox (http://standards.ieee.org/regauth/oui/oui.txt) Not that it will
probably cause us any problem, but a multicast address is afaik an
invalid mac for a device. Should we go for 01:allzeros?
--
Luis Carlos Cobo Rus GnuPG ID: 44019B60
cozybit Inc.
On Mon, 2008-07-28 at 17:44 +0300, Tomas Winkler wrote:
> On Mon, Jul 28, 2008 at 5:25 PM, Michael Buesch <[email protected]> wrote:
> > On Monday 28 July 2008 15:57:45 Dan Williams wrote:
> >> > (What are the udev problems, btw?)
> >>
> >> People seem to want persistent device names. Since the kernel doesn't
> >> provide stable device/bus enumeration, there are udev hacks (see
> >> attached from Fedora 9) that read the MAC address of the card on
> >> hot-plug and then assign it to a cached device name so that every time I
> >> plug in my Netgear MA401 it gets "eth2".
> >
> > Yeah well. But using a pseudo-random MAC as a base to build a persistent
> > naming scheme on sounds pretty fragile to me. ;)
> >
> > I think cards that don't supply MAC early simply cannot support
> > a really working persistent naming scheme well. udev should probably
> > just enumerate eth0 - ethX as it sees the devices. That's as good
> > as mixing a numbering scheme into a pseudo MAC, IMO. And it's
> > less confusing and it pushes a lot of policy decisions into userspace.
>
> Can devices supply something depending on its bus numbering that will
> not change unless it's plugged out.
Doesn't even need to provide it, udev can look at all that info if it
wants.
johannes
On Mon, 2008-07-28 at 18:58 +0300, Tomas Winkler wrote:
> On Mon, Jul 28, 2008 at 6:14 PM, Dan Williams <[email protected]> wrote:
> > On Mon, 2008-07-28 at 17:07 +0200, Johannes Berg wrote:
> >> On Mon, 2008-07-28 at 10:59 -0400, Dan Williams wrote:
> >>
> >> > > If that's really a problem, yes. 01:00:00:00:00:00 is still better
> >> > > than a pseudo random MAC, IMO. It's immediately obvious to the user
> >> > > that the MAC currently is not set.
> >> >
> >> > How about 44:44:44:44:44:44 like orinoco uses for bogus BSSID? If we
> >> > can, let's not keep creating yet more bogus MAC addresses.
> >>
> >> Either way, the problem is that these will confuse udev if you have two
> >> at the same time, no?
> >
> > the udev script I attached from Fedora 9 already ignores devices with
> > 00:00:00::: so I don't think we'd have a problem with that. Screw the
> > Xerox thing, all zeros is just bogus and tons of stuff treats it that
> > way already.
>
> So this won't conflict even if you have two or more devices that
> claims zero mac address?
Well, sane udev persistent name rules should be ignoring invalid MAC
addresses, and right now they just happen to ignore 00:00:00::: already
anyway. Apparently the one I posted also handles the MAC changing later
and does the right thing.
So if you have two cards with the same MAC, they'll still get different
netdevs, just if they are both 00:00:00::: this udev script I posted
won't try to rename them at all, so everything is fine.
If you have two cards with the same MAC that's _valid_, then stuff gets
screwed up (*cough* libertas + mesh *cough*) but that's not our problem.
Dan
On Mon, 2008-07-28 at 10:59 -0400, Dan Williams wrote:
> > If that's really a problem, yes. 01:00:00:00:00:00 is still better
> > than a pseudo random MAC, IMO. It's immediately obvious to the user
> > that the MAC currently is not set.
>
> How about 44:44:44:44:44:44 like orinoco uses for bogus BSSID? If we
> can, let's not keep creating yet more bogus MAC addresses.
Either way, the problem is that these will confuse udev if you have two
at the same time, no?
johannes