I have many identical Cisco MR18 devices and want to synchronise their config, with this specific fragment:
config device option name 'eth0' option macaddr '00:18:0a:XX:XX:XX'
The macaddr is a Cisco one from the hardware, which was presumably populated by LuCI.
To avoid the need to tailor the file for each device, I investigated it it was possible to just use default it and indeed the user guide says:
macaddr string Required:no Default:(none) MAC address overriding the default one for this device, e.g. 62:11:22:aa:bb:cc
Commenting it out and rebooting however puts the system on a random MAC address (different each boot) and not the Cisco-prefixed one of the hardware.
Which is incorrect, the system or the doc? This is 24.10.4. It's certainly preferred to use the hardware MAC rather than explicitly listing it in a config.
I would treat the doc as saying only that macaddr is not required, not that OpenWrt can always recover the vendor MAC by itself. If the device/driver is exposing a random address before your config is applied, leaving the option out will just keep that random fallback. For cloning configs I would either keep that one line templated per MR18, or generate it on first boot from wherever the board stores the Cisco MAC if that is available on this target.
I appreciate some devices won't know the vendor's MAC, but this one does as it populated the initial configuration with it. Surely the MAC is set on the eth0 interface at very early boot, rather than established in the process of making a default configuration to a file?
Small check that may narrow it down: compare the MAC in /rom/etc/board.json (or /etc/board.json after first boot) with cat /sys/class/net/eth0/address before your config is applied. If the board data has the Cisco address but the live interface comes up random when macaddr is absent, then the docs are probably incomplete for this target/driver path. In that case I would keep macaddr templated from board data rather than leaving it blank.
Thanks, I would love to upgrade, but I'm prevented from using 25.x because of another issue where one of the radios will not initialise. If I'm able to resolve that I'll be very happy. If I find time I'll do an isolated test to see what the current behaviour is, followed by a revert back to 24.x.