Parveke16 Posted August 3, 2016 Posted August 3, 2016 Hello, I liked to have fixed MAC address to my Orange Pi lite. At the moment, after every boot I have different one. First of all, is there "real" MAC for this board? If there is, how the see it? Then what would be correct way to set static MAC, U-boot/Scribt.bin/ifconfig...? I am running Armbian 5.14 Jessie server.
martinayotte Posted August 3, 2016 Posted August 3, 2016 Maybe there was something missing in 5.14, but in 5.17 the firstrun script is creating the file : /etc/modprobe.d/8189fs.conf, it should looks like : options 8189fs rtw_initmac=00:e0:4c:f5:16:d8
zador.blood.stained Posted August 3, 2016 Posted August 3, 2016 Maybe there was something missing in 5.14, but in 5.17 the firstrun script is creating the file : /etc/modprobe.d/8189fs.conf, it should looks like : options 8189fs rtw_initmac=00:e0:4c:f5:16:d8 Since latest prebuilt images are of version 5.14 and firstrun script won't be executed after dist-upgrade, this change doesn't work yet.
Parveke16 Posted August 3, 2016 Author Posted August 3, 2016 Maybe there was something missing in 5.14, but in 5.17 the firstrun script is creating the file : /etc/modprobe.d/8189fs.conf, it should looks like : options 8189fs rtw_initmac=00:e0:4c:f5:16:d8 There is such file, and it looks: options 8189fs rtw_initmac=43:29:B1:0C:84:1C But, it gives address from 00:E0:4C: -range
martinayotte Posted August 3, 2016 Posted August 3, 2016 I'm using Mainline 4.6.2, and this /etc/modprobe.d/8189fs.conf works for me, it keep the same MAC at every reboot. But I don't know if the same happen in Legacy kernel.
zador.blood.stained Posted August 3, 2016 Posted August 3, 2016 I'm using Mainline 4.6.2, and this /etc/modprobe.d/8189fs.conf works for me, it keep the same MAC at every reboot. But I don't know if the same happen in Legacy kernel. Just checked: this is what happens /* * Description: * rtw_check_invalid_mac_address: * This is only used for checking mac address valid or not. * * Input: * adapter: mac_address pointer. * check_local_bit: check locally bit or not. * * Output: * _TRUE: The mac address is invalid. * _FALSE: The mac address is valid. * * Auther: Isaac.Li */ u8 rtw_check_invalid_mac_address(u8 *mac_addr, u8 check_local_bit) { u8 null_mac_addr[ETH_ALEN] = {0, 0, 0, 0, 0, 0}; u8 multi_mac_addr[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff}; u8 res = _FALSE; if (_rtw_memcmp(mac_addr, null_mac_addr, ETH_ALEN)) { res = _TRUE; goto func_exit; } if (_rtw_memcmp(mac_addr, multi_mac_addr, ETH_ALEN)) { res = _TRUE; goto func_exit; } if (mac_addr[0] & BIT0) { res = _TRUE; goto func_exit; } if (check_local_bit == _TRUE) { if (mac_addr[0] & BIT1) { res = _TRUE; goto func_exit; } } func_exit: return res; } So in case bits 0 or 1 of first byte of MAC address are set, 8189fs driver won't consider this MAC "valid" and will assign a random one. And firstrun always sets first byte as 0x43, which is 10000112 Edit: Added comments to function code to clarify return value logic.
tkaiser Posted August 3, 2016 Posted August 3, 2016 And firstrun always sets first byte as 0x43, which is 10000112 So I added just another bug when adding this to firstun The MAC prefix 00:e0:4c is registered for RealTek so should we switch to this in firstrun?
zador.blood.stained Posted August 3, 2016 Posted August 3, 2016 The MAC prefix 00:e0:4c is registered for RealTek so should we switch to this in firstrun? Yes, but I would prefer to check mainline driver too.
martinayotte Posted August 3, 2016 Posted August 3, 2016 That's explain everything ... If I remember when I faced the same issue, I've explicitly copied the current MAC into the 8189fs.conf file, so I "fixed" the issue by placing a 00:e0:4c manually. In mainline, it looks like the same code, because in fact, when I commit it, the sources was merged with Hans changes, but origins are common. I see that the random init is using this code : *((u32 *)(&mac[2])) = rtw_random32(); mac[0] = 0x00; mac[1] = 0xe0; mac[2] = 0x4c; So, Yes, the firstrun should place the same RealTek prefix.
Parveke16 Posted August 5, 2016 Author Posted August 5, 2016 Okay, now I have static MAC. I edited both firstrun and 8189fs.conf. Was that correct way, at least it seem to work. Thank You.
kudzu Posted August 28, 2016 Posted August 28, 2016 What about [dynamic] MAC = "XXXXXXXXXXXX" in script.bin?
zador.blood.stained Posted August 28, 2016 Posted August 28, 2016 What about [dynamic] MAC = "XXXXXXXXXXXX" in script.bin? It should be possible to make 8189fs driver read this value, but I'm not sure that this is really needed
Drakoh Posted September 15, 2016 Posted September 15, 2016 I'd like to achieve the same as OP, but on a OrangePI PC with mainline kernel and u-boot. If I set a fix mac address in the /etc/network/interfaces, the board doesn't boot, so I guess there should be another way to do it.
martinayotte Posted September 15, 2016 Posted September 15, 2016 In mainline, you can add parameter in ethernet@1c30000 (or &emac) section like : mac-address = [aa e3 14 b9 b5 12];
Drakoh Posted September 15, 2016 Posted September 15, 2016 In mainline, you can add parameter in ethernet@1c30000 (or &emac) section like : mac-address = [aa e3 14 b9 b5 12]; Pardon my noobness, but to which file should I add this? script.bin? boot.cmd? somethingelse?
martinayotte Posted September 16, 2016 Posted September 16, 2016 You were asking "for mainline", so device-tree files. Using 'dtc' compiler, you have to decompile the DTB file into a DTS, add the above property, and recompile it back into a new DTB. (Keep a backup of the old DTB, just in case)
Elliot Woods Posted August 27, 2017 Posted August 27, 2017 I'm testing on Armbian mainline now OPi Zero Armbian 5.27.170614 need to achieve static mac address per boot in the next 12 hours before 200 OPiZ's get silicone sealed into waterproof containers. so looking into this now... also adding notes for others with same issue who might also be less familiar with the inner workings of armbian and/or linux tried adding the file: /etc/modprobe.d/8189fs.conf (note that file didn't exist before) and setting its contents to: options 8189fs rtw_initmac=00:e0:4c:f5:16:d8 but that didn't help (new random MAC address on reboot) theres a file /etc/default/brcm40183 with: MAC_ADDR=43:29:B1:55:01:01 which doesn't correspond to any of the mac addresses its chosen at boot so far as I know (also this seems to be cubietrick specific?) also similar in /etc/default/ap6212 found the lines in /etc/init.d/firstrun: # set MAC for eth0 255: MACADDR=$(printf 'da:42:ea:%02X:%02X:%02X\n' $[RANDOM%256] $[RANDOM%256] $[RANDOM%256]) 256: sed -i "s/^\#[^ tab]\+hwaddress ether/\thwaddress ether $MACADDR/" /etc/network/interfaces 257 ;; will investigate here..
Elliot Woods Posted August 27, 2017 Posted August 27, 2017 also very curious how to re-activate the firstrun script after it's run the first time already (especially how to run it unattended, i.e. flag for it to be run for next boot)
Elliot Woods Posted August 27, 2017 Posted August 27, 2017 manually running : sed -i "s/^\#[^ tab]\+hwaddress ether/\thwaddress ether 00:e0:4c:55:01:01/" /etc/network/interfaces and rebooted still a random address (this time `d6:e2:72:eb:b4:e9`)
Elliot Woods Posted August 27, 2017 Posted August 27, 2017 got some hints from the other thread: especially on how best to misuse an internet forum / your life so I keep hearing about 'device tree' looking at the linked code: https://github.com/megous/linux/blob/orange-pi-4.11/drivers/net/ethernet/allwinner/sun8i-emac.c#L1221-L1226 it looks like if of_get_mac_address fails to get a mac address from of_node then it will assign a random one so i guess that in order to succeed we need to fix Device Tree? i didn't have this issue on the legacy kernel (but need docker, so need mainline kernel) any primer notes on Device Tree ?
zador.blood.stained Posted August 27, 2017 Posted August 27, 2017 52 minutes ago, Elliot Woods said: it looks like if of_get_mac_address fails to get a mac address from of_node then it will assign a random one so i guess that in order to succeed we need to fix Device Tree? MAC address should be set by u-boot first. In order to find network devices it looks for aliases named ethernetX (where X is a number) pointing to the network devices DT nodes. In the source DT an alias looks like this: https://github.com/megous/linux/blob/orange-pi-4.11/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts#L58 Regarding the wireless driver - no idea if it supports a fixed MAC address and what method should be used for it. Edit: the first OPi Zero uses the XRadio driver, not a Realtek one, and current mainline images don't have this driver at all in the kernel sources due to many issues with it) 1 hour ago, Elliot Woods said: need to achieve static mac address per boot in the next 12 hours before 200 OPiZ's get silicone sealed into waterproof containers. so looking into this now... If you are using mainline kernel for production and it works good enough for you (even though I would not recommend it, especially for OPi Zero) - okay, fine, but please use apt-mark hold to freeze the kernel, DT and board support packages (or remove /etc/apt/sources.list.d/armbian.list) to minimize the chance of getting a 200 waterproof useless bricks broken by the upgrade.
martinayotte Posted August 27, 2017 Posted August 27, 2017 @zador.blood.stained, I've discovered some thing funny ... In sun8i-h2-plus-orangepi-zero.dts, there is a comment in the alias section : /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */ But it seems that it is not true any more, neither in sun8i-h3.dtsi or sunxi-h3-h5.dtsi ! So, that is why we lost fix MAC on few boards when we switched from 4.10 to 4.11 ... I will prepare a patch in the following minutes ...
zador.blood.stained Posted August 27, 2017 Posted August 27, 2017 3 minutes ago, martinayotte said: But it seems that it is not true any more, neither in sun8i-h3.dtsi or sunxi-h3-h5.dtsi ! Yes, I noticed this too just now when I was looking for an example alias.
martinayotte Posted August 27, 2017 Posted August 27, 2017 Patch committed : https://github.com/armbian/build/commit/90b771cdf28b43cf6a857eeb10b204c38c7de82a 2
Elliot Woods Posted August 27, 2017 Posted August 27, 2017 @martinayotte hah interesting! so now i just need to wait for the nightly build server to kick in? and then i can have fixed mac address? @zador.blood.stained thanks for the tips! are you suggesting that the kernel might update itself automatically? or that i might do it myself by accident at some point?
martinayotte Posted August 27, 2017 Posted August 27, 2017 7 minutes ago, Elliot Woods said: now i just need to wait for the nightly build server You can also decompile DT, edit by adding this alias, and recompile it.
Elliot Woods Posted August 27, 2017 Posted August 27, 2017 Just now, martinayotte said: You can also decompile DT, edit by adding this alias, and recompile it. any references on how to do that? sorry to ask if it's an obvious thing.
martinayotte Posted August 27, 2017 Posted August 27, 2017 Assuming you have "dtc" installed (and keep a backup of the original /boot/dtb/sun8i-h2-plus-orangepi-zero.dtb : dtc -I dtb -O dts -o sun8i-h2plus-orangepi-zero.dts-4.11.12 /boot/dtb/sun8i-h2-plus-orangepi-zero.dtb Edit the DTS with "nano sun8i-h2plus-orangepi-zero.dts-4.11.12" and add 'ethernet0 = "/soc/ethernet@1c30000"; ' in the "aliases" section. Then, recompile the DTB : dtc -I dts -O dtb -o /boot/dtb/sun8i-h2-plus-orangepi-zero.dtb sun8i-h2plus-orangepi-zero.dts-4.11.12 1
Elliot Woods Posted August 27, 2017 Posted August 27, 2017 magic! it works!! thank you so much sun8i-h2plus-orangepi-zero.dts-4.11.12 file for reference: https://gist.github.com/elliotwoods/02cfef1c79babb91a14a2e555b9d8da2
Elliot Woods Posted August 27, 2017 Posted August 27, 2017 final question : how to make sure that the MAC address will be randomised on next boot? (and not on subsequent boots)
Recommended Posts