At least on my Acer One D250 dmidecode provides a mainboard
UUID.
Sebastian
Stupid me,
I had a closer look at the UUID and they are using one scheme
supported by uuidgen where the last 6 bytes are the MAC
address *of eth0*
___
On Tuesday 24 November 2009 09:51:37 Oncaphillis wrote:
On 11/20/2009 12:12 PM, Michael Buesch wrote:
This patch adds a generic mechanism for overriding the SPROM mechanism
on devices without SPROM hardware.
There currently is a major problem with this:
It tries to deduce a MAC address
This patch adds a generic mechanism for overriding the SPROM mechanism
on devices without SPROM hardware.
There currently is a major problem with this:
It tries to deduce a MAC address from various hardware parameters. But
currently it will result in the same MAC address for machines of the same
On Friday 20 November 2009 12:38:07 Florian Fainelli wrote:
Why not call once random_ether_addr instead of using some kind of hash? Is it
because you
want the same MAC from a reboot to another?
yes.
Ok, so for BCM63xx I would no longer have to declare my SPROM, fine.
No you still need to
On 11/20/2009 05:12 AM, Michael Buesch wrote:
This patch adds a generic mechanism for overriding the SPROM mechanism
on devices without SPROM hardware.
There currently is a major problem with this:
It tries to deduce a MAC address from various hardware parameters. But
currently it will
Hi
On Friday 20 November 2009, Larry Finger wrote:
On 11/20/2009 05:12 AM, Michael Buesch wrote:
[...]
You might look at the root= part of /proc/cmdline. Mine says
root=/dev/disk/by-id/ata-TOSHIBA_MK2546GSX_18C2P0KCT-part1. That disk serial
number would certainly be unique. Even if it just
You might look at the root= part of /proc/cmdline. Mine says
root=/dev/disk/by-id/ata-TOSHIBA_MK2546GSX_18C2P0KCT-part1. That disk
serial
number would certainly be unique. Even if it just said root=/dev/sda1, it
would be repeatable.
Ok, I think this is getting ugly :)
The problem with all
On 11/20/2009 08:11 AM, Michael Buesch wrote:
Ok, I think this is getting ugly :)
The problem with all this is that if you change the harddisk, or change the
partitioning,
the wireless mac address would change. That would surely lead to confusion.
I think we probably have to drop this
On 11/20/2009 08:50 AM, Ehud Gavron wrote:
How does WL do it? Broadcom *has* to generate a MAC address that is
both unique and in its assigned range. If we can do the same thing in
B43 that would be ideal.
They are memory mapping a file in /etc/wlan. How this file is generated is not
known.
Larry Finger wrote:
On 11/20/2009 05:12 AM, Michael Buesch wrote:
This patch adds a generic mechanism for overriding the SPROM mechanism
on devices without SPROM hardware.
There currently is a major problem with this:
It tries to deduce a MAC address from various hardware parameters.
On 11/20/2009 04:36 PM, Bartłomiej Ochman wrote:
Oncaphillis wrote:
At least on my Acer One D250 dmidecode provides a mainboard
UUID.
Who's the vendor of ethernet chip in this acer? Broadcom too?
lspci tells me its broadcom
See the lspci under
http://oncaphillis.net/lspci-aspire-d250.txt
11 matches
Mail list logo
