On 03/23/2010 03:58 PM, Calvin Walton wrote:
I will warn you that the following is rather untested, as I don't have
any of the affected hardware (or any b43 devices at all, actually), but
something along these lines should work. There's no syntax errors, at
least :)
---
On Wednesday 24 March 2010 15:16:03 Larry Finger wrote:
I have modified ssb to supply a MAC address of 80:80:80:80:80:80, rather than
What about also setting the local-assignment bit for this temporary address?
The one remaining problem is that the interface has already been renamed
before
On Tuesday 23 March 2010 00:45:28 Larry Finger wrote:
(2) In drivers/ssb/pci.c, the firmware loading process reads the file, then
modifies it using the bus address.
No. You don't need firmware loading at all.
udev can just set the mac address through the standard ioctl calls.
Just like how
On Tuesday 23 March 2010 09:55:39 Florian Fainelli wrote:
Why not use random_ether_addr and only use the digits that you are interested
in?
Because it's not constant across reboots.
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
On 03/23/2010 03:52 AM, Michael Buesch wrote:
On Tuesday 23 March 2010 00:45:28 Larry Finger wrote:
(2) In drivers/ssb/pci.c, the firmware loading process reads the file, then
modifies it using the bus address.
No. You don't need firmware loading at all.
udev can just set the mac address
On Tuesday 23 March 2010 21:58:22 Calvin Walton wrote:
On Tue, 2010-03-23 at 09:25 -0500, Larry Finger wrote:
Will someone please write me udev rule(s) that do the following:
1. Detect a MAC address of FF:FF:FF:FF:FF:FF
2. If this is the first time for this bus address, then generate a
Michael Buesch wrote:
On Monday 22 March 2010 22:56:44 Larry Finger wrote:
Does anyone have any suggestions on what characteristic could be used to
generate a unique MAC address for a box in a udev rule?
/dev/urandom
Yeah, there's the chance of clashes. In practice there won't be
On Monday 22 March 2010 07:28:23 Calvin Walton wrote:
Hi,
On Sat, 2010-03-20 at 19:14 -0500, Larry Finger wrote:
Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
from the SPROM could be included in the kernel; however, this presents
a problem in the generation of a
On 03/22/2010 03:37 AM, Michael Buesch wrote:
On Monday 22 March 2010 07:28:23 Calvin Walton wrote:
Hi,
On Sat, 2010-03-20 at 19:14 -0500, Larry Finger wrote:
Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
from the SPROM could be included in the kernel; however, this
On 03/22/2010 04:55 PM, Michael Buesch wrote:
I don't see a problem for udev to distinguish the cards. It can do it merely
on
the bus-ID. That's unique. Yeah, it might change if you change the hardware.
But do we care? I say no, because you cannot actually change the hardware in
real life
On Monday 22 March 2010 22:56:44 Larry Finger wrote:
Does anyone have any suggestions on what characteristic could be used to
generate a unique MAC address for a box in a udev rule?
/dev/urandom
Yeah, there's the chance of clashes. In practice there won't be any clashes,
however. If you think
On Monday 22 March 2010 23:19:54 Larry Finger wrote:
On 03/22/2010 04:55 PM, Michael Buesch wrote:
I don't see a problem for udev to distinguish the cards. It can do it
merely on
the bus-ID. That's unique. Yeah, it might change if you change the hardware.
But do we care? I say no,
Michael,
Would the following be sufficient?
(1) The utility /bin/dbus-uuidgen is used to create a file
/lib/firmware/ssb/mac_address. The command to create this file if it does not
exist could be added to the scripts that use fwcutter.
(2) In drivers/ssb/pci.c, the firmware loading process
Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
from the SPROM could be included in the kernel; however, this presents
a problem in the generation of a unique, reproducible MAC address. The
solution has been to create a utility that generates a virtual SPROM
image with a
14 matches
Mail list logo
