Constantly changing MAC (nanopi r5c)

I'm testing a nanopi r5c running openwrt and the MAC keeps changing on reboot.
Is there a way to get the factory MAC back and keep it so it doesn't change on reboots?

I cannot hard code the MAC in the network file because I use the same image to flash other of the same device.

This is what I'm using at the moment;

There appears to be a rather recent open bug related to this:

Does the bug described in that link match the observed symptoms?

You can work around this bug by using the UCI defaults mechanism. This involves writing a script that reads the factory MAC addresses (or generates a random MAC) and applies it via UCI upon first start. That way you can use the same image on all your devices while still having unique and stable MAC addresses.



It's nice to read there's a way then.
Yes, I need it to be the factory MAC as that's how I keep track of my devices.

I'll look into this and see if I can find more information.
If I solve it, I'll share how I did it here.

Thanks for responding and the lead.

UCI commands would not work because when I write a new firmware file to the device, it would not retain the permanent MAC address.

About the only way I can think of is to run a script on first ever bootup that writes to a small custom partition or something.

Or, if there was some way to find the original factory MAC address on bootup, like some way to dig deep into the hardware, then use that to set it, that could work.

However, I've read there is no way that anyone knows of to do that using OpenWrt.

Oddly, I have another of these r5c devices and the first one is running the same flashed openwrt but doesn't change MAC on reboot.

That's literally what the UCI defaults mechanism is. You write a script that gets built into the firmware image, which will run on first boot. Don't worry, you don't need to compile from source, you can use the Image Builder to include your desired script.

Where did you read that? Every OpenWrt device has some way to obtain the factory programmed MAC address. The exact mechanism varies between devices. For the NanoPi R5C, we can take a look at the original commit that added OpenWrt support. According to the script that sets up the MAC addresses, the MAC addresses are actually derived from the eMMC card identifier (CID):

    wan_mac=$(macaddr_generate_from_mmc_cid mmcblk*)
    lan_mac=$(macaddr_add "$wan_mac" 1)

The macaddr_generate_from_mmc_cid function comes from this script:

macaddr_generate_from_mmc_cid() {
    local mmc_dev=$1
    local sd_hash=$(sha256sum /sys/class/block/$mmc_dev/device/cid)
    local mac_base=$(macaddr_canonicalize "$(echo "${sd_hash}" | dd bs=1 count=12 2>/dev/null)")
    echo "$(macaddr_unsetbit_mc "$(macaddr_setbit_la "${mac_base}")")"

I have no idea why this doesn't work on your device. But as you state:

This makes me wonder if one of your devices has some eMMC weirdness that prevents the above scripts from working. On the affected device, can you see if the following command works?

sha256sum /sys/class/block/mmcblk0/device/cid
1 Like

It's good to know there is a way to find the original MAC.
I just went ahead and set some in my files/etc/network file.

However, I'd love to know how this can be done but did find something out. It seems these routers are sold as regular and enterprise. Regular have dynamic MAC while enterprise ones have static MAC.

Because of this, I suspect there will be no original MAC to be found on the hardware.
I'd love to try your method but I'm not following how I can do this.

Sorry I overlooked your suggestion, here is the result.

# sha256sum /sys/class/block/mmcblk2/device/cid
203b87071a83ead6bba84d9a93a5dc1d9d3944afe34f5a4a5938fd71b00b87ad  /sys/class/block/mmcblk2/device/cid

So it appears that OpenWrt is able to pick up the CID. Does that value change between reboots? A changing CID would result in a changing MAC address if I'm reading the R5C-specific code correctly.

1 Like

The CID is supposed to be chip metadata written once at the factory. It won't change on rebooting, however it may not necessarily be a way to derive unique MAC addresses. Some cheap eMMC chips might not have serial numbers or other unit-unique information (or any information) burned into their CID.

1 Like

In the case of this device, the CID is unique to the eMMC so it doesn't change which means it can be used to generate unique MAC addresses.

Thanks to all for the help on this.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.