I have several Compute Module 4s which are running OS images from cloned SD cards.
The OS is Raspberry Pi OS, aarm64 edition, Buster version.
The wlan0 interfaces on the CM4 modules all have the same MAC address.
I can tell they have the same MAC address by observing the behaviour of my DHCP server; each SD card has a unique hostname configured (post-cloning), which is visible to the DHCP server, but the same IP lease is getting reissued to multiple different CM4s. I can also tell by running
ip addr on each CM4 module (via SSH connections over wired Ethernet) and observing that the hardware address for wlan0 is the same on all of them.
Clearly, this MAC address must be set by something in the OS image, rather than being derived from a unique ID burned into the SoC.
I have already tried deleting the contents of
/etc/machine-id and rebooting the machine, since I've seen old forum Q+As recommending that. This resulted in a new
machine-id value but the wlan0 MAC address did not change.
Question: How are the MAC addresses for wlan and eth interfaces generated in Raspberry Pi OS Buster, and what do I need to change to ensure that each device gets a unique but persistent MAC address wlan0 regardless of eth0's MAC address? Ideally, the answer should be something that can be done to the base image on the SD card before the CM4 is booted for the first time, rather than something that needs to be done interactively on a running RPi. A script that can be inserted into the systemd init sequence would be ok.
For bonus points: is there any difference between Buster and Bullseye in how the MAC addresses are generated?
cat /etc/os-release returns:
PRETTY_NAME="Debian GNU/Linux 10 (buster)" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"
uname -a returns
Linux [hostname] 5.4.72-v8-ipipe+ #3 SMP PREEMPT Tue Sep 14 14:57:29 +07 2021 aarch64 GNU/Linux
cat /etc/apt/sources.list.d/raspi.list returns
deb http://archive.raspberrypi.org/debian/ buster main # Uncomment line below then 'apt-get update' to enable 'apt-get source' #deb-src http://archive.raspberrypi.org/debian/ buster main
AFAICT, this all corresponds to Raspberry Pi OS Buster, compiled for aarch64. This image does have some non-standard kernel modules (discussed below), so it's likely an unofficial kernel build, but otherwise using standard RPi OS Buster userland.
Status of NetworkManager and systemd-networkd
I think NetworkManager is not installed;
apt list --installed *etwork* returns nothing.
systemctl status systemd-networkd returns
● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-networkd.service(8)
Looks like that's installed but not being used either? I'm not an expert in Linux sysadmin so I might be misinterpreting this output.
/boot/config.txt doesn't mention anything about MAC addresses.
console=serial0,115200 console=serial1,115200 console=tty1 root=PARTUUID=886950bd-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait isolcpus=2,3 xenomai.supported_cpus=0xC
I suspect that a fixed MAC address might have been configured for eth0, since these machines are doing some realtime stuff with Xenomai using eth0 interface, which needs to know eth0's MAC address to start up. Possibly wlan0's MAC address is fixed because it's generated from the eth0 MAC.
Where should I look for overrides of the eth0 MAC address configuration?
Can you point me to the location of the logic which configures the wlan's MAC based on the integrated eth interface's MAC?
More info on the OS: it's PiCAT 4, which is derived from Raspberry Pi OS Buster version, as the OS self-identification information above makes clear. It has all the standard Raspberry Pi OS Buster userland packages such as
raspi-config. But it looks like it replaces the standard Buster kernel with a custom 64-bit kernel build with Xenomai, IgH Etherlab EtherCAT master and a few other custom kernel modules added in.
The requirements of the EtherCAT master are the likely reason for the eth0 interface having an overridden MAC, which might be causing the wlan0 MAC to be overridden as an undesired side-effect. But I still don't know where to look to find the MAC override for either interface.