after boot, /lib/firmware/smsc75xx/ethmacaddr0 is created , it’s content is 58:fc:db:40:20:fa . i tried to modify this file, but it failed saying Read-only file system.
echo “58:fc:db:40:20:fb” | sudo tee /lib/firmware/smsc75xx/ethmacaddr0
Could you please suggest how to modify/set write permissions for /lib/firmware content files. So that i will be able to set mac address after booting in target
similar thing i need to do for the firmware/wlan//macaddr0 for wifi also.
In short … there is no way, you can only do it at build time … /lib/firmware is a bind-mount of /snap/<kernel-snap>/firmware and that is inside a loop mounted and gpg signed squashfs file …
you can do the same in the install scriptlet that is done for wlan/macaddr0 and ship a dangling symlink in the snap pointing to /var/snap/<your-daemon-snap>/current/ethmacaddr0 … and then have a daemon snap that fills this file with content …
We are able to overwrite the mac address (/lib/firmware/smsc75xx/ethmacaddr0) in case of debian/ubuntu version rootfs
even in the case of scriplets for wlan/macaddr0 it is choosing based on the androidboot.serialno . but later it has to be changed for each board will be assigned different mac address based on the mac address recieved for that hardware.
echo “58:fc:db:40:20:fa” | sudo tee /run/macaddr0
this changes at that moment only, after reboot, wlan mac address retains the old one based on androidboot.serialno.
[this script should actually first need to pick the programmed mac address, if it is not present it should set based on .serialno]
scriplet is part of snapcore, how do i need to build my own script and integrate to ubuntu-xenial(kernel.snap) and dragonboard gadget.snap and build the .img
you can not modify the initrd, nor can you modify the readonly rootfs or the readonly kernel, this is by (security-)design
the method i described above is the only way to do it without making any incompatible changes to the system …
Edit: indeed you can patch the drivers themselves in the kernel tree to look at certain writable places (like /run) that you then fill from a daemon snap … (or patch them to read a kernel cmdline option)
now if you create a /run/ethaddr0 (from a snap for example) the mac address should be read from there … (if the smsc75xx driver supports that behaviour indeed)
after booting from sdcard or even after reboot after first boot, it does not creates this file /run/ethaddr0.
i guess in case of wifi, snapcraft core is creating /run/macaddr0 file and writing content to it
ln -s /run/macaddr0 $SNAPCRAFT_PART_INSTALL/firmware/wlan/
i am able to create a snap and install in --devmode and /run/ethmacaddr0 got created.
in the uboot.env.in i had added this args=androidboot.serialno=f2103d96 ethmacaddr=58fcdb4020fe
so it will have persistent storage. I can change the ethmacaddr for each boards in uboot or using fw_setenv
But it creates only when i run that snap. is it possible to run that snap by default before ethernet(smsc75xx) driver gets loaded.
is it possible to build the custom core-build ? so that i can modify the dragonmac and add a new ethmacaddr script also
ethmacaddr
#!/bin/sh -e
initramfs local-premount script to set a
mac address on the dragonboard
PREREQ=""
Output pre-requisites
prereqs()
{
echo “$PREREQ”
}
case “$1” in
prereqs)
prereqs
exit 0
;;
esac
if [ -e /proc/device-tree/model ]; then
if grep -q “APQ 8016” /proc/device-tree/model; then
if grep -q ethmacaddr /proc/cmdline; then
for i in $(cat /proc/cmdline); do
case “$i” in
ethmacaddr=*)
echo “${i#ethmacaddr=}”|
sed ‘s/.{2}/&:/g;s/.$//’ >/run/ethmacaddr0
;;
esac
done
fi
fi
fi
for a second interface just add an additional line to the config file… after configuring it once the devices should come up with the new MAC addresses on each boot …
mac spoofing does not work always, i tried multiple reboots, it does not sets the mac addresses assigned in /var/snap/mac-spoofer/current/config . it picks the random mac addresses for interafces.
While you could do that for development, a custom core is not upgradeable, the same goes for the kernel snap if you change the initrd … i’d suggest to rather find out why exactly the mac spoofer snap does not work (does it run to early ? try adding some sleep to the script for a test) and fix that …
as i said above, this is a workaound for a bug in the driver introduced by the 96board guys. if the driver gets fixed to actually use ROM code as it should, the link in /run as well as the script in initrd will be removed. This is nothing permanent, normally MAC addresses are set form the hardware.
did you look at that “daemon” ? it is a script that only executes 3 lines of ip/ifconfig commands per device, nothing more … (and technically the poper way to do this if your network devices actually operate according to the spec)
In the old world (when using ifupdown) you would have used /etc/network/interfaces and added something like:
hwaddress ether 00:01:04:1b:2C:1F
to that file to set a mac address from software, but Ubuntu Core uses netplan instead of ifupdown which does not support this feature yet, so the call to “ip link set <device> address <addr>” is the proper fallback way until netplan grows such a feature. the initrd hack will go away as soon as the driver is fixed by upstream to read from the ROM or to use the devicetree for the address.
"this is a workaound for a bug in the driver introduced by the 96board guys. if the driver gets fixed to actually use ROM code "
this is not going to get fixed. dragonboard is already manufactured without any EEPROM on board. so the mac address has to be stored in emmc only.
the initrd hack will go away as soon as the driver is fixed by upstream to read from the ROM or to use the devicetree for the address.
since there is no ROM, i guess you are talking about storing the MAC addresses in devicetree(apq8016-sbc-snappy.dtsi)
In this case if there are 100 boards, each boards should be flashed with different .img by building different kernel snaps with modification in the .dtsi file.
Not really … it will likely just feed the devicetree from the lk during boot (by using the board serial), similar to to the pending patch used for setting the BT address at:
