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)
In ubuntu-xenial.git , snapcraft.yaml they had linked the /run/macaddr0 to firmware/wlan/macaddr0
i need some clarification how does this scriplet blob/master/initramfs/scripts/local-premount/dragonmac get executed and writes to /run/macaddr0
so i need to create /run/ethmacddr0 and link to firmware/smc75xx/ethmacaddr0
Could you please give some reference or pointer?
well, you gave the pointer yourself above already … with a slight modification it should just work for smsc75xx:
install: |
...
mkdir -p $SNAPCRAFT_PART_INSTALL/firmware/smsc75xx
ln -s /run/ethaddr0 $SNAPCRAFT_PART_INSTALL/firmware/smsc75xx/
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)
when i modified the file snapcraft.yaml
mkdir -p $SNAPCRAFT_PART_INSTALL/firmware/smsc75xx
ln -s /run/ethaddr0 $SNAPCRAFT_PART_INSTALL/firmware/smsc75xx/
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/
as i said a few times above, you have to create this file from a snap or script …
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
#!/bin/sh -e
PREREQ=""
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
name: ifc6309-mac
version: ‘0.1’
summary: ethernet programming
description: |
ethernet mac address programming
confinement: strict
apps:
ethmacaddr:
command: ethmacaddr
plugs: [network, network-control]
parts:
ethmacaddr:
source: .
plugin: dump
organize:
ethmacaddr : usr/bin/ethmacaddr
well … i created a snap for you … do:
snap install mac-spoofer --edge
then follow the instructions at:
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 …
i installed and tried the snap, i am able to set the macaddresses for eth0, eth1 and wlan0.
if we spoof the mac address, i guess we do not even need the
snapcore/core-build/blob/master/initramfs/scripts/local-premount/dragonmac
**but if we go with this approach, boot up time took almost 2minutes. **
Is this a feasible solution?
vinaysimha@localhost:~$ cat /var/snap/mac-spoofer/current/config
eth1 58:fc:db:40:20:a1
eth0 58:fc:db:40:20:a2
wlan0 58:fc:db:40:20:a3
vinaysimha@localhost:~$
vinaysimha@localhost:~$ ifconfig -a
eth0 Link encap:Ethernet HWaddr 58:fc:db:40:20:a2
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth1 Link encap:Ethernet HWaddr 58:fc:db:40:20:a1
inet6 addr: fe80::5afc:dbff:fe40:20a1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:59 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4634 (4.6 KB) TX bytes:712 (712.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:160 errors:0 dropped:0 overruns:0 frame:0
TX packets:160 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:12800 (12.8 KB) TX bytes:12800 (12.8 KB)
sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
wlan0 Link encap:Ethernet HWaddr 58:fc:db:40:20:a3
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
i assume not all of your network cards are configured ?
that would be:
(a fix for this bug is still being researched)
fyi,
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.
it is set from a snap, so it will only spoof once the daemon in the snap gets started (check again after waiting a little)
i tried multiple reboots, sometimes mac address set properly, sometimes not. it is having random behaviour
i want to build the custom core-build ? so that i can modify the dragonmac and add a new ethmacaddr script for initramfs
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 …
core-build/blob/master/initramfs/scripts/local-premount/dragonmac
is just a temporary solution for having unique mac address, We should program the actual mac address
this should change
from echo “0200${i#androidboot.serialno=}”|
to
echo “${i#androidboot.serialno=}”|
androidboot.serialno will be programmed once after the boot.
the similar way it should be applicable to ethmaccdr programming.
Why we need to run a daemon everytime at boot? if we can have permanent solution in persisent storage.
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.
I have filed a whishlist bug at:
"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:
.serialno is the eMMC CID.
As you had mentioned earlier this post fix for bt mac address, similar for wlan also.
This is a temporary solution to ensure that each board gets a unique MAC address, provided by the bootloader. there is on going work to get rid of this hack and store MAc addresses in a persistent area on the eMMC
i just had an IRC discussion with the 96boards maintainer that cares for the dragonboard:
<ogra_> ndec, do you plan do do a similar fix as https://git.linaro.org/landing-teams/working/qualcomm/lk.git/commit/?h=release/LA.BR.1.2.7-03810-8x16.0&id=372982a4d4c4922e9214ff7d6aa5348aaba602a7 for the wlan address at some point (i'd really like t get rid of the initrd hack to feed /run/macaddr0 at some point)
<ndec> ogra_: hi! it's done for wlan already. it was done before the bt stuff actually.
<ndec> this commit is before the one you linked: https://git.linaro.org/landing-teams/working/qualcomm/lk.git/commit/?h=release/LA.BR.1.2.7-03810-8x16.0&id=d27b915da64b5e3bc2f672cc8757ce523bf1b89c
<ndec> and the driver already has support, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/ath/wcn36xx/main.c#n1279
<ndec> ogra_: btw, these days, we are trying to define a 'provision' file that would contain the 'real' MAC addresses for wlan and bt.
<ndec> the provisioning would/could be done in production (or re-done by end users)
<ndec> no, the bootloader will read that 'provision info' and populate the DTB at run time
<ogra_> with no fallback to serial at all ?
<ndec> yes, with a fallback.
<ogra_> ah
<ndec> the thing is that the boards are being provisioned with real MAC address (Arrow bought them). and right now they are not being used
<ndec> QCOM already has a 'solution' for this problem in their Windows 10 image. we are trying to reuse their provisioning file format.
<ogra_> so what would happen if i dropped the /run/macaddr0 hack right now (assuming i have the lk and kernel patches indeed)
<ndec> ogra_: nothing would happen, it would just work ;-)
so in that light, expect the script in the initrd to go away soon … (but you should be able to use the mentioned “provision” file at some point, until then i’d still recommend using something like the mac-spoofer snap)
so we need to wait for this ‘provision’ file to have permanent solution