Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-24 Thread Larry Finger 
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/rules.d/65-persistent-b43-mac-generator.rules
 
 ACTION!=add GOTO=persistent_b43_mac_generator_end
 
 SUBSYSTEM==net, DRIVERS==b43, ATTR{address}==ff:ff:ff:ff:ff:ff, 
 IMPORT{program}=write_persistent_b43_mac
 
 SUBSYSTEM==net, ENV{MACADDRESS_NEW}==?*, RUN+=ifconfig $env{INTERFACE} 
 hw ether $env{MACADDRESS_NEW}
 
 LABEL=persistent_b43_mac_generator_end
 
 --- /lib/udev/write_persistent_b43_mac (chmod +x)
 
 #!/bin/bash
 
 # This mac address generation function could be replaced with something better
 MACADDRESS=$(dd if=/dev/urandom bs=1 count=6 2/dev/null | od -tx1 | head -1 
 | cut -d' ' -f2- | awk '{ print $1:$2:$3:$4:$5:$6 }')
 
 RULES_FILE='/etc/udev/rules.d/60-persistent-b43-mac.rules'
 
 . /lib64/udev/rule_generator.functions
 
 lock_rules_file
 
 choose_rules_file
 
 echo DEVPATH==\$DEVPATH\, DRIVERS==\b43\, 
 ATTR{address}==\ff:ff:ff:ff:ff:ff\, RUN+=\ifconfig $INTERFACE hw ether 
 $MACADDRESS\  $RULES_FILE
 
 echo MACADDRESS_NEW=$MACADDRESS
 
 unlock_rules_file
 
 ---
 
 A new file /etc/udev/rules.d/60-persistent-b43-mac.rules will be
 created, which will contain the the saved mac address and bypass the
 generating script on future boots.
 
 This should probably be run by the udev maintainers, but is a start,
 anyways.

Thanks for the really good start.

The above routines have a minor problem in that using a random value for the
first byte of the MAC address runs the risk of having the multicast bit set. By
fixing the first one to a multiple of 4, that problem is avoided.

A second minor problem is that the full path must be given for all standard
utilities, otherwise they are assumed to be in /lib/udev. Thus all references to
ifconfig were replaced by /sbin/ifconfig. I hope all distros put ifconfig in
/sbin.

I have modified ssb to supply a MAC address of 80:80:80:80:80:80, rather than
FF:FF:FF:FF:FF:FF. This way the interface can come up even though the new udev
routines are not available. When b43 detects that address, it will log a message
describing why the udev routines are needed, and how to obtain them.

The one remaining problem is that the interface has already been renamed before
60-persistent-b43-mac.rules is processed. In my case, the interface is wlan13,
not wlan0. After I manually modified 60-..., then the new address is applied.
I'm still working on this problem.

Thanks again for the help.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-24 Thread Michael Buesch 
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
 60-persistent-b43-mac.rules is processed. In my case, the interface is wlan13,
 not wlan0. After I manually modified 60-..., then the new address is applied.
 I'm still working on this problem.

Well, udev scripts are processed in alphabetical order. Can't you simply run
the persistent mac rules before the persistent ifname rules?

-- 
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-23 Thread Michael Buesch 
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 ifconfig and ip can do.

-- 
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-23 Thread Michael Buesch 
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@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-23 Thread Larry Finger 
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 through the standard ioctl calls.
 Just like how ifconfig and ip can do.

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 random MAC
address with the bus address encoded in it.
3. Preserve the address for future reloads
4. Load the saved address into the device.
5. Do the above with only standard external commands - no new programs

My skills with udev are not up to the task.

I now have code running that uses the firmware load facility to read a
file created by /bin/dbus-uuidgen to create a MAC address that will satisfy the
requirements. If the file is needed but not available, then the user is prompted
with the commands needed to create it.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-23 Thread Michael Buesch 
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 random 
  MAC
  address with the bus address encoded in it.
  3. Preserve the address for future reloads
  4. Load the saved address into the device.
  5. Do the above with only standard external commands - no new programs
  
  My skills with udev are not up to the task.
 
 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/rules.d/65-persistent-b43-mac-generator.rules
 
 ACTION!=add GOTO=persistent_b43_mac_generator_end
 
 SUBSYSTEM==net, DRIVERS==b43, ATTR{address}==ff:ff:ff:ff:ff:ff, 
 IMPORT{program}=write_persistent_b43_mac
 
 SUBSYSTEM==net, ENV{MACADDRESS_NEW}==?*, RUN+=ifconfig $env{INTERFACE} 
 hw ether $env{MACADDRESS_NEW}
 
 LABEL=persistent_b43_mac_generator_end
 
 --- /lib/udev/write_persistent_b43_mac (chmod +x)
 
 #!/bin/bash
 
 # This mac address generation function could be replaced with something better
 MACADDRESS=$(dd if=/dev/urandom bs=1 count=6 2/dev/null | od -tx1 | head -1 
 | cut -d' ' -f2- | awk '{ print $1:$2:$3:$4:$5:$6 }')
 
 RULES_FILE='/etc/udev/rules.d/60-persistent-b43-mac.rules'
 
 . /lib64/udev/rule_generator.functions
 
 lock_rules_file
 
 choose_rules_file
 
 echo DEVPATH==\$DEVPATH\, DRIVERS==\b43\, 
 ATTR{address}==\ff:ff:ff:ff:ff:ff\, RUN+=\ifconfig $INTERFACE hw ether 
 $MACADDRESS\  $RULES_FILE
 
 echo MACADDRESS_NEW=$MACADDRESS
 
 unlock_rules_file
 
 ---
 
 A new file /etc/udev/rules.d/60-persistent-b43-mac.rules will be
 created, which will contain the the saved mac address and bypass the
 generating script on future boots.
 
 This should probably be run by the udev maintainers, but is a start,
 anyways.
 
 

Thanks a lot for this proof of concept. This looks very nice.

-- 
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-23 Thread Ehud Gavron 



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 any clashes,
however. If you think there's a real risk, you should start playing
the lottery tomorrow. You'll immediately win a million dollars so you don't have
to worry about those questions anymore. ;)

In fact, I think the risk for mac clashes is not really reduced by generating 
the mac
address from serial numbers, whatever, etc...

  

DEC used the L3 address to encode a new MAC at the time the [L3] address was
set (DECnet v4).  The advantage was they didn't need to use the equivalent
of ARP.  Of course this is a violation of strict layer separation.

Octet1-Octet3 - Broadcom assigned MAC IDs.  I found the following:
00-05-B5
00-10-18
00-1B-E9
18-C0-86

Octet4-octet6 - Lowest three octets of the unixtime.


Advantages: for the local area network all TZ settings should be the same,
so the MAC addresses *will* be different.  Beyond the first router that 
won't

matter.  Also for the same machine different interfaces are GUARANTEED
to have different MAC addresses.

For two machines to have the same MAC they would have to be booted at
(same time x processing factor) such that the B43 initialization will 
result

in the same MAC address.  I'd like to think those odds are even lower than
your lottery.

A million dollars?  
http://www.active-domain.com/resources/million-dollar-domains.htm

Yeah got the t-shirt.


E



smime.p7s
Description: S/MIME Cryptographic Signature
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-22 Thread Michael Buesch 
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 unique, reproducible MAC address. The
  solution has been to create a utility that generates a virtual SPROM
  image with a random MAC address. This image is stored in the firmware
  area, and loaded using the asyncronous firmware load facility.
 
 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 due to the fixed filename.
 
 Instead of using a firmware file to load in the MAC address, might it be
 possible to move the persistent MAC setting to a simple udev rule which
 generates a persistent MAC address, saves it, then sets it each boot
 using a command like ip link set wlan0 address XX:XX:XX:XX:XX:XX ?
 
 This would remove the need to have this fake firmware file available
 at boot, provided that the driver can handle leaving the address
 unconfigured until userspace gets around to setting it. As well, it
 could be written to work with multiple cards easily, saving a different
 MAC for each.
 
 Some thoughts for your consideration,
 

I think this actually is a very good idea.
This way we could live without a user-supplied sprom image, which I would 
_really_
prefer. 

-- 
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-22 Thread Larry Finger 
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 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 random MAC address. This image is stored in the firmware
 area, and loaded using the asyncronous firmware load facility.

 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 due to the fixed filename.

 Instead of using a firmware file to load in the MAC address, might it be
 possible to move the persistent MAC setting to a simple udev rule which
 generates a persistent MAC address, saves it, then sets it each boot
 using a command like ip link set wlan0 address XX:XX:XX:XX:XX:XX ?

 This would remove the need to have this fake firmware file available
 at boot, provided that the driver can handle leaving the address
 unconfigured until userspace gets around to setting it. As well, it
 could be written to work with multiple cards easily, saving a different
 MAC for each.

 Some thoughts for your consideration,

 
 I think this actually is a very good idea.
 This way we could live without a user-supplied sprom image, which I would 
 _really_
 prefer. 

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
space at all. Any suggestions?

Larry


___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-22 Thread Larry Finger 
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
 for any of these devices. And even if you could reorder the devices on the 
 bus or whatever.
 What would happen? The card would get a new MAC address. That's all. That's 
 acceptable.
 
 The kernel would (for example) just set the mac address to all-ones. Udev 
 would
 notice this (invalid) mac address and reassign a new persistent one to the 
 device. It then
 stores the address on the harddisk.

What ensures that this persistent name would be unique?

 In fact, if we implement a mechanism in the kernel, we have _exactly_ the 
 same problem.
 However, currently Larry's patches just ignore that problem and assume that 
 there's only
 one card in the system anyway.

As I said in a posting a few minutes ago, that problem is solved.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-22 Thread Michael Buesch 
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 there's a real risk, you should start playing
the lottery tomorrow. You'll immediately win a million dollars so you don't have
to worry about those questions anymore. ;)

In fact, I think the risk for mac clashes is not really reduced by generating 
the mac
address from serial numbers, whatever, etc...

-- 
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-22 Thread Michael Buesch 
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, because you cannot actually change the hardware 
  in real life
  for any of these devices. And even if you could reorder the devices on the 
  bus or whatever.
  What would happen? The card would get a new MAC address. That's all. That's 
  acceptable.
  
  The kernel would (for example) just set the mac address to all-ones. Udev 
  would
  notice this (invalid) mac address and reassign a new persistent one to the 
  device. It then
  stores the address on the harddisk.
 
 What ensures that this persistent name would be unique?

The same mechanism that ensures that an UUID is unique: A good random number 
generator.

  In fact, if we implement a mechanism in the kernel, we have _exactly_ the 
  same problem.
  However, currently Larry's patches just ignore that problem and assume that 
  there's only
  one card in the system anyway.
 
 As I said in a posting a few minutes ago, that problem is solved.

Well. You distinguish by bus-ID, right? That's exactly the thing that udev does.

-- 
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Re: [PATCH V2] ssb: Implement virtual SPROM on disk

2010-03-22 Thread Larry Finger 
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 the file, then
modifies it using the bus address.

I think this process would create a persistent MAC address that is unique within
the box, with a small probability of being duplicated on another machine.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev