Page 1 of 1

Using Raspberry Pi MAC addresses for commercial products based on Compute Module?

Posted: Sat Jan 19, 2019 9:08 pm
by pi3g
Using Raspberry Pi MAC addresses for commercial products based on Compute Module?

@Raspberry Pi Foundation / Trading Ltd., I hope this is the appropriate forum to place the question:

Hi,

we're currently building a Raspberry Pi Compute Module based embedded solution - an industrial carrier board for the compute module, which will include the SMSC LAN 9512 USB Hub & Ethernet chip. It is built for a specific customer, but is going to be available on the broad market. Our goal is to make an affordable solution, which will have interesting industrial features like 24 V, etc. But I digress ...

I am wondering whether we need to acquire our own MAC address space from the IEEE, (and maybe design in an EEPROM for that), or whether we can use the Raspberry Pi provided & set MAC from the Raspberry Pi Foundation MAC pool b8:27:eb:...?

I understand the MAC is set by the Broadcom Firmware (start.elf).

Thank you for your feedback!
Max

P.S: If anyone is interested in the carrier board, please get in touch via https://pi3g.com/kontakt

Re: Using Raspberry Pi MAC addresses for commercial products based on Compute Module?

Posted: Sat Jan 19, 2019 9:15 pm
by DougieLawson
The mac address is not secure. You can easily spoof it.

There's also only 24-bits of uniqueness. First 24-bits are fixed. We've seen address wrap-around as there are already more than 16million pis out there in the wild and with a random assignment wrap-around occurred before the 16million were sold.

You can override it with the kernel cmdline.

Re: Using Raspberry Pi MAC addresses for commercial products based on Compute Module?

Posted: Sat Jan 19, 2019 10:01 pm
by pi3g
Thank you, very insightful!

I'll look some more into it; at least a design-in of the EEPROM can't hurt, we can always simply not place it.

Re: Using Raspberry Pi MAC addresses for commercial products based on Compute Module?

Posted: Sun Jan 20, 2019 4:22 pm
by incognitum
DougieLawson wrote:
Sat Jan 19, 2019 9:15 pm
You can override it with the kernel cmdline.
Recall you can also program a custom MAC in OTP with the right config.txt option, if you want it more permanent.

Re: Using Raspberry Pi MAC addresses for commercial products based on Compute Module?

Posted: Sun Jan 20, 2019 4:46 pm
by gsh
Yes that's correct... program_mac_address is your friend..

Gordon

Re: Using Raspberry Pi MAC addresses for commercial products based on Compute Module?

Posted: Sun Jan 20, 2019 5:46 pm
by pi3g
Thank you very much for the info about program_mac_address ! This sounds very promising.

@Gordon Could you please acknowledge that I am correct in understanding the following:

1) it is not necessary to set up an EEPROM to store a different MAC address in the Pi permanently
* in fact, if we implement such a EEPROM, we are on our own, as Raspberry Pi do not use one in their designs
2) the custom MAC address is set (for the SMSC LAN device) by
* adding to config.txt program_mac_address=xx:xx:xx:xx:xx:xx
* booting the pi, the MAC address will be saved to OTP fields 64/65
* then program_mac_address=xx:xx:xx:xx:xx:xx can be removed from config.txt
3) Once it has been set to the OTP fields, it can't be changed by specifying a different program_mac_address value (as these are one time programmable fields)
4) leaving program_mac_address=xx:xx:xx:xx:xx:xx inside config.txt would be OK as well, it does not need to be removed

I found these references:

Re: Using Raspberry Pi MAC addresses for commercial products based on Compute Module?

Posted: Sun Jan 20, 2019 5:52 pm
by gsh
1) it is not necessary to set up an EEPROM to store a different MAC address in the Pi permanently
* in fact, if we implement such a EEPROM, we are on our own, as Raspberry Pi do not use one in their designs
Correct
2) the custom MAC address is set (for the SMSC LAN device) by
* adding to config.txt program_mac_address=xx:xx:xx:xx:xx:xx
* booting the pi, the MAC address will be saved to OTP fields 64/65
* then program_mac_address=xx:xx:xx:xx:xx:xx can be removed from config.txt
Correct
3) Once it has been set to the OTP fields, it can't be changed by specifying a different program_mac_address value (as these are one time programmable fields)
Correct
4) leaving program_mac_address=xx:xx:xx:xx:xx:xx inside config.txt would be OK as well, it does not need to be removed
Correct

In the end the result of adding program_mac_address is as you say programming a couple of lines in the OTP. When start.elf boots, it reads these and if they are set adds the address to the device_tree.

Re: Using Raspberry Pi MAC addresses for commercial products based on Compute Module?

Posted: Sun Jan 20, 2019 6:14 pm
by pi3g
Thank you! - Max

Re: Using Raspberry Pi MAC addresses for commercial products based on Compute Module?

Posted: Thu Feb 28, 2019 4:52 pm
by Conner Labs
I designed a similar industrial board, but using TWO LAN9512s. I was unaware of the program_mac_address command (maybe it didn't even exist at the time I did the design?) but I found that EEPROMs worked fine.

I used to have to add a malformed MAC address to cmdline.txt to make the Raspberry Pi foundation's code choke on it and fall through to the code in the LAN95xx driver that reads the EEPROM. This doesn't seem to be needed any more in Jessie though.

But anyway, this thread has me wondering what the program_mac_address thing would do with the second LAN9512? Could I save an EEPROM by storing one of the MAC addresses in OTP? Or would it set them both the same, etc...

Steve

Re: Using Raspberry Pi MAC addresses for commercial products based on Compute Module?

Posted: Fri Mar 01, 2019 4:43 pm
by incognitum
Conner Labs wrote:
Thu Feb 28, 2019 4:52 pm
But anyway, this thread has me wondering what the program_mac_address thing would do with the second LAN9512? Could I save an EEPROM by storing one of the MAC addresses in OTP? Or would it set them both the same, etc...
Recall firmware sets the local-mac-address property of whatever device has been given the alias ethernet0 in device-tree.
Which with the default device-tree files would be the device at address usb1@1

Also wonder if perhaps you couldn't (ab)use the HAT ID EEPROM interface to specify the addresses for both with a single EEPROM.
Can't that be used to feed the system arbitrary device-tree overlays overriding things?!