MAC addresses hard-coded in bootloader
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| snap-core18 |
Fix Released
|
Critical
|
Unassigned | ||
Bug Description
Posting this on behalf of a customer:
After a significant amount of support tickets over the years with customers complaining about colliding MAC addresses, we have *finally* been able to get our heads around *why* this is.
Backstory:
A common scenario for customers is that they have a single Raspberry Pi at their office at HQ (or similar) where they prepare their devices. They flash out the SD cards and once they're done setting the devices up, they either ship the SD cards out to the location (where they might already have drop-shipped the hardware from the supplier directly).
The reason why this is relevant is because Core will *hardcode* the MAC Address as part of the SD card (in /boot/uboot/
The reason why we were finally able to reproduce this ourselves was because a similar workflow. We created 48 SD cards that we shipped off to a data center for our QC rig. When they booted up in their new home, the network collapsed because it had 48 devices all using the same MAC Address.
Reproducing this is easy:
* Flash out a Core18 image to an SD cards
* Boot it up on a Raspberry Pi and observe the MAC addresses
* Shut the device down
* Move it to a different Raspberry Pi and boot it up
You will now notice that the MAC Address is the same.
We used fw_printenv to find the values set in uboot.env and then remove them with fw_setenv. Unfortunately, this did not update uboot.env.
| Changed in snap-core18: | |
| status: | New → Confirmed |
| importance: | Undecided → Critical |
| Dave Jones (waveform) wrote | #1 |
| Viktor Petersson (vpetersson) wrote | #2 |
| Viktor Petersson (vpetersson) wrote | #3 |
| Viktor Petersson (vpetersson) wrote | #4 |
| Dave Jones (waveform) wrote | #5 |
| tags: | added: fr-851 |
| Changed in snap-core18: | |
| status: | Confirmed → Fix Released |
This is occurring because the Core 18 boot environment uses "saveenv" to save its state, which dumps the *entire* U-Boot environment (including settings like ethaddr, and serial#) to disk. A workaround, as you've noted, is to edit the U-Boot environment in place to remove these settings. In the following GitHub gist you should find a small Python script I wrote a while ago (and just polished up a bit) which can accomplish this:
https:/
Just save the script to a file named "edit-env", make it executable, and run it with the name of the U-Boot environment you wish to edit. It should open the environment as a series of key=value lines in the system's default editor. For example:
$ wget https:/
$ chmod +x edit-env
$ ./edit-env uboot.env
You will need to delete the following settings from the environment:
serial#
ethaddr
usbethaddr
serial# must be deleted as well as the ethaddr value is partially derived from it, and just to pre-empt the obvious question: yes, U-Boot sets the board's serial number in the device-tree from that value so all the boards in question will currently have the same serial number at runtime.
In the meantime, I'll see if I can whip up a more sensible core18 boot environment.