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 rand
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
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; how
On Monday 22 March 2010 16:06:34 Larry Finger wrote:
> Avoiding the use of a new user-space program would be desirable, but I cannot
> think of any way that a udev rule could distinguish one card from another. If
> we
> had any unique features such as a serial number, then we wouldn't need user
>
On 03/22/2010 01:28 AM, Calvin Walton wrote:
>
> I'm curious, how would this firmware-loading scheme deal with having
> multiple cards of this type installed? This seems like an unusual
> situation, but it looks like this patch will cause all of the cards to
> start up with the same MAC address du
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
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 s
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 reads
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 ifc
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
Bcm43xx-dev@l
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 add
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 gene
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 an
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 :)
>
> --- /lib/udev/ru
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 03/24/2010 02:21 PM, Michael Buesch wrote:
> 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
17 matches
Mail list logo