Jump to content

Opi Zero MAC address issue on Mainline kernel

Recommended Posts



After running the default image with legacy kernel for a few weeks, I am now trying the run a fresh SD card with the latest build of the mainline image. However, the MAC address of my device appears to be changing after each reboot - and I am running about of ideas to fix this issue. What I've tried so far:

- Edit script.bin & add MAC address in the [dynamic] section

- Edit armbianEnv.txt

- Define an address in /etc/network/interfaces


So far, I have not been able to solve the problem. Your help is much appreciated. Any suggestions on possible fixes for the issue?

Link to comment
Share on other sites

Same here.

/etc/modprobe.d/xradio_wlan.conf seems to to fix an initial MAC via a driver option - I cannot check whether this works because the rulers of this world disabled WLAN support for the OPi-zero.

There does not seem to be a corresponding file for the ethernet driver.


Link to comment
Share on other sites

Mainline = experimental, no support. Network driver will be changed.

Armbian support feels like a bunch of parrots each time one of those questions from experimental area pops out :P


Link to comment
Share on other sites

OK, until elegant way is restored, add it to your /etc/rc.local

# In order to enable or disable this script just change the execution
# bits.
# By default this script does nothing.

/sbin/ifconfig eth0 down
/sbin/ifconfig eth0 hw ether 02:22:EA:F1:41:C5
/sbin/ifconfig eth0 up
/bin/systemctl restart NetworkManager

exit 0


Link to comment
Share on other sites

23 minutes ago, umiddelb said:

You can hardwire the MAC address in


Look for

hwaddress ether


hwaddress ether 00:01:c0:13:fb:ef


man 5 interfaces

for more details.

Well, since NetworkManager is doing all the hard work:


cat /etc/network/interfaces
source /etc/network/interfaces.d/*
# This file intentionally left blank
# All interfaces are handled by network-manager, use nmtui or nmcli on
# server/headless images or the "Network Manager" GUI on desktop images


Link to comment
Share on other sites

7 hours ago, lukaszjokiel said:

since NetworkManager is doing all the hard work

...workarounds should maybe addressed at the NetworkManager level too (nmcli can be used to add a so called 'Cloned MAC address' to a connection profile and with nmtui --> 'Edit Connection' it's that easy that everyone should be able to manage this). The other way to create something like /etc/network/interfaces.d/eth0 as @umiddelbsuggested (taking Ethernet out of control of NetworkManager) will work of course too.


Just to prevent the next step happen (NM blaming/whining). This is not a NetworkManager issue, it's about users misusing so called 'devel images' for production purposes, ignoring warnings and struggling with them. There are fully supported legacy Armbian images that are not marked as 'experimental' and this whole thread is as unbelievable as all the others dealing with the same 'problem' before.

Link to comment
Share on other sites

Can some one help me, please, clarify - why mainline image changes wired ethernet port MAC address every reboot? Legacy image doesn't do that - but i need overlayroot support, so I have to use mainline (I tried legacy - overlayroot was not working).

Link to comment
Share on other sites

1 hour ago, KuDeSnik33ra said:

Can some one help me, please, clarify

There is no support in legacy kernel for overlayroot because kernel is too old for this function, while mainline kernel is not on the (end user) level for using it. https://forum.armbian.com/index.php?/topic/4239-opi-zero-mac-address-issue-on-mainline-kernel/&do=findComment&comment=32623


Link to comment
Share on other sites

4 hours ago, Stanislav Sinyagin said:

I'm fine with experimental status, but just wondering, how did 4.10.3-sun8i memorize the MAC address, and why 4.11.3-sun8i does not?

Don't know. The main problem with development kernel(s) is that is difficult to stay on track to understand changes. Each question might lead into deep investigation which is not possible.

I know one important detail - current network driver is deprecated / not good for mainline / half broken and somebody is working on a new one. Getting to know why the problem is present in current kernel is therefore pure waste of time. This issue is a school example, why support for WIP is pointless.

You can try with workarounds to set MAC until things are solved.


More or less updated status can be found here: http://linux-sunxi.org/Linux_mainlining_effort

We have some general troubles and changes with nightly builds. Repository will be rebuilt daily, while images weekly.



Link to comment
Share on other sites

5 hours ago, Stanislav Sinyagin said:

I can help with Perl or shell scripting, if needed

Help is welcomed and needed. Of course.


On any of those three major projects:

- build engine https://github.com/armbian/build (shell)

- configuration utility https://github.com/armbian/config (shell)

- general documentations https://github.com/armbian/documentation (text)


Start something simple to get you going - configuration utility needs some fine touch / adding new features rework into cleaner code, than proceed to hard nuts :)

Link to comment
Share on other sites

Hi everyone,


Is this problem already solved? I keep trying to use hwaddress xx:xx:xx:yy:yy:yy  or hwaddress ether xx:xx:xx:yy:yy:yy option on /etc/network/interfaces configuration file with no success. I also tried the pre-up ifconfig hw ether xx:xx:xx:yy:yy:yy, but with no success either. 


I keep having to manually put interface down with ifdown, then reconfigure its HW address and after that, restart NetworkManager and then renew the DHCP process.


The main problem is that sometimes this process is not 100% realiable and home router gets 2 DHCP negotiations, one for the RANDOM MAC address and the other for the manually configured MAC address.


Any clues? 



Rodrigo Matias



Link to comment
Share on other sites

This topic is now closed to further replies.
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines