1

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?

Update 1

OS Identification

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 configuration

/boot/config.txt doesn't mention anything about MAC addresses. /boot/cmdline.txt is 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?

Update 2

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.

8
  • 1
    the wifi MAC address should be eth0 MAC address xor 1 I believe - unless you've made some sort of changes to the default install, or perhaps using NetworkManager or systemd-networkd to manage your network interfaces - side note: I don't think there was ever an official Raspberry Pi OS Buster aarm64 edition. Mar 1, 2023 at 7:52
  • is there any mention of mac address in /boot/config.txt or /boot/cmdline.txt? Mar 1, 2023 at 8:06
  • 1
    MAC addresses are fundamentally derived from serial number (although there have been changes in the rules over time). They are not necessarily unique but the chances of duplicates are vanishing small. THEY ARE FIXED AND DO NOT CHANGE although it is possible to override the hardware value. You have not demonstrated any basis for your question.
    – Milliways
    Mar 1, 2023 at 8:45
  • My problem is that when I put the cloned SD cards into two different CM4 modules, they both observably connect to a wifi AP using identical MAC addresses. I've customised the hostnames on each SD card, and I can see the DHCP lease being reissued to a host with a different hostname but the same MAC. I'm trying to figure out where this MAC address is coming from since the OS image must be overriding the hardware value - I'm just not sure where/how. Mar 1, 2023 at 8:51
  • @Milliways question updated with additional sourcing of my claim that the CM4s are all using the same wifi MAC. Mar 1, 2023 at 8:57

1 Answer 1

1

If you really want to change MAC (just to clarify attempting to change OTP is not advisable as you can't just overwrite you can only set 1 bits) but presumably whatever software you are using is ignoring the value.
See https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#otp-register-and-bit-definitions.

Presumably whatever OS (or application) you are using changes this.

Some OS in a misguided attempt at security attempt to randomise MAC. If done properly (as MacOS does) this helps stop tracking devices, but a fixed MAC is used for established connections.

5
  • I'd be happy to use the default policy for configuring the wlan MAC based on hardware serial. That would give me what I want: a persistent but (near-)unique wifi MAC for each CM. I don't need it to be dynamic or randomised. I think the real problem is that I don't understand how the OS image is currently overriding the MAC, which is why I asked for information about how Raspberry Pi OS sets the MAC address. Mar 1, 2023 at 9:20
  • 1
    Raspberry Pi OS DOES NOT set the MAC address - it is done by firmware. AFAIK wlan MAC is derived from eth MAC - in my case on Pi4 Bullseye it is just +1 (earlier OS used different rules)
    – Milliways
    Mar 1, 2023 at 9:31
  • Well, let me reframe the question, then. When Raspberry Pi OS is configured to override the hardware/firmware MAC address with a software-defined MAC address (which is definitely possible), what are the possible mechanisms for configuring that override? (Other than /boot/config.txt and /boot/cmdline.txt which I have already ruled out) Mar 1, 2023 at 10:18
  • Does the firmware compute the wlan MAC address from the Eth MAC address, or is that done by Linux? Mar 1, 2023 at 10:21
  • I definitely haven't written a firmware update to the CM4 to overwrite the OTP MAC, but I suppose it's conceivable that a script in the OS might be writing to the OTP. I'll try booting the CM4 from a more standard RPi OS image and see what MAC address it uses when there's no customisations in place... Mar 1, 2023 at 10:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.