[ZeroW2] kcmdline paramter `smsc95xx.macaddr` contains older OUI in MAC value

[samveen]

Is this the right place for my bug report? Yes: This is regarding the calculation of the value for the kernel command line parameter smsc95xx.macaddr

Description of the bug On the Raspberry Pi Zero 2 W, the OUI prefix of the MAC addresses used in the WiFi devices is e4:5f:01:xx:xx:xx:

samveen@zero2w:~ $ ip -o link sh dev wlan0 | sed 's/:[0-9a-f][0-9a-f]:[0-9a-f][0-9a-f]:[0-9a-f][0-9a-f] /:xx:xx:xx /'
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DORMANT group default qlen 1000\    link/ether e4:5f:01:xx:xx:xx brd ff:ff:ff:ff:ff:ff

However the value of the parameter smsc95xx.macaddr calculated and sent to the kernel is with the older OUI prefix B8:27:EB:XX:XX:XX:

samveen@zero2w:~ $ cat /proc/cmdline  | sed 's/:[0-9A-F][0-9A-F]:[0-9A-F][0-9A-F]:[0-9A-F][0-9A-F] /:XX:XX:XX /'
coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=Composite-1:720x480@60i smsc95xx.macaddr=B8:27:EB:XX:XX:XX vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  console=tty1 console=ttyS0,115200 root=PARTUUID=d65d6b68-02 rootfstype=ext4 fsck.repair=yes rootwait

To reproduce

• Boot up a raspberry pi zero W 2
• cat /proc/cmdline
• ip -o link sh dev wlan0
• Compare the prefix of the wlan MAC to the paramter supplied to the kernel command line

Expected behaviour The kernel command line should have an OUI prefix of E4:5F:01:XX:XX:XX for the kernel command line parameter smsc95xx.macaddr

Actual behaviour The kernel command line uses the older OUI prefix of B8:27:EB:XX:XX:XX for the kernel command line parameter smsc95xx.macaddr

System

Raspberry Pi Zero 2 W Rev 1.0
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
--
Raspberry Pi reference 2022-04-04
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 27a8050c3c06e567c794620394a8c2d74262a516, stage2
--
Linux zero2w.cluster.samveen.in 5.15.76-v8+ #1597 SMP PREEMPT Fri Nov 4 12:16:41 GMT 2022 aarch64 GNU/Linux
Revision    : 902120
Serial      : xxxxxx
Model       : Raspberry Pi Zero 2 W Rev 1.0
Throttled flag  : throttled=0x0
Camera          : supported=0 detected=0, libcamera interfaces=0
--
Videocore information
---------------------

Oct 26 2022 11:10:35 
Copyright (c) 2012 Broadcom
version c72ad6b26ff40c91ef776b847436094ee63fabee (clean) (release) (start)

alloc failures:     0
compactions:        0
legacy block fails: 0

References:

• https://pip.raspberrypi.com/categories/685/documents/RP-003474-WP/RP-003474-WP-1.pdf
• https://standards-oui.ieee.org/oui/.txt

[timg236]

There’s no Ethernet on pizero2 so no reservations is made in the new range for that. The WiFi allocation is independent of msc95xx.macaddr.

Edit: The WiFi MAC address is stored in the OTP of the WiFi module and the firmware has no knowledge of this because it's a property of the module rather than the SOC.

[pelwell]

The command line says "if there is an SMSC95xx Ethernet interface then its MAC address should be the following". This does nothing if there is no such interface. You could argue that the parameter is unnecessary and should be removed, especially since the same information is now conveyed via Device Tree, but there could well be non-DT-based systems out there (bare metal OSes, etc.) that rely on the command line.

[samveen]

@timg236 I've been leveraging the mac address value of smsc95xx.macaddr to stabilized the transient macs generated by my enc28j60 modules. The reason I asked for this change is that any network identification tools based on OUIs will misidentify my device, when connected to a wired network.

@pelwell Yes Phil. I'm doing exactly that: I rely on the command line to apply a static mac address to the SPI ethernet modules I've connected to my Zero,Zero W and Zero W 2s (which get transient MACs on every reboot).

That said, I'm realize I'm being pedantic, and that this issue is possibly the lowest possible priority issue in the whole raspi organiztion. Please feel free to close it if the pedantry is beyond acceptable limits :smile:

[pelwell]

The problem here is that on the Zero 2 W the WLAN MAC addresses (currently in the E4:5F:01:XX:XX:XX range) are programmed into the WiFi chip during manufacture, and the firmware does not contain (and will never contain) enough software to enable them to be read back.

[timg236]

NB On BCM2711 you can’t assume that the OUIs for Ethernet/WiFi/BT will be the same either. The only way to get the WiFi MAC is to ask the interface. If you want to allocate your own MAC then you can write this to customer OTP OR generate something from the serial number at runtime. NB The OUIs will also change without warning as more devices are made. We just document the ones in use so far