MAC-Address of eth0 changes on every boot.

[wollik]

Hi All,
I''m using a BPI M2 Zero, where a 100 MBit ethernet Interface is implemented on the board. Since I'm using DHCP for this interface, I found that the MAC Address of this eth0 interface changes on every boot. The MAC Address of the wlan0 interface is permanent and don't changes during boots.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Di 30. Jun xx:xx:xx  CEST 2020
Debian GNU/Linux 10 (buster)
5.4.45-sunxi
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 17:42:11 up 25 min,  2 users,  load average: 0,00, 0,00, 0,05
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 8a:aa:ea:69:67:50  txqueuelen 1000  (Ethernet)
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether cc:b8:a8:a9:bc:8e  txqueuelen 1000  (Ethernet)
 

 17:46:04 up 0 min,  2 users,  load average: 2,48, 0,70, 0,24
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 5e:af:c0:93:75:72  txqueuelen 1000  (Ethernet)
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether cc:b8:a8:a9:bc:8e  txqueuelen 1000  (Ethernet)

 

 17:47:07 up 0 min,  2 users,  load average: 1,92, 0,44, 0,14
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 56:e7:62:af:35:55  txqueuelen 1000  (Ethernet)
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether cc:b8:a8:a9:bc:8e  txqueuelen 1000  (Ethernet)

 

 17:48:23 up 0 min,  2 users,  load average: 1,69, 0,39, 0,13
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 96:57:7c:ed:85:e0  txqueuelen 1000  (Ethernet)
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether cc:b8:a8:a9:bc:8e  txqueuelen 1000  (Ethernet)

 

 

Is there a way to set the MAC address of the eth0 interface to a fix value ?

Regards
WolliK

[xwiggen]

yes this is an issue with newest downloadable buster image, been meaning to fix that but no time yet at hand.

workaround for classic specification (/etc/network/interfaces)

auto eth0
iface eth0 inet dhcp
        hwaddress ether 12:34:56:78:9A:BC

 

or set dhcp-client-identifier 12:34:56:78:9A:BC in dhclient.conf (https://linux.die.net/man/5/dhclient.conf)

 

[wollik]

Hi xwiggen,
T H A N K  you, that  solves my MAC address problems.

 

Regards
WolliK

[MariuszJo]

I've seen that pull request for this in ticket AR-352. However, I am still experiencing change of the MAC address on every reboot Nano Pi NEO with "Armbian 20.08.1 Bionic with Linux 5.8.5-sunxi". Is this a known problem?

Edited November 21, 2020 by MariuszJo
Additonal information

[TRS-80]

Hi @MariuszJo, and welcome to the forums.

 

On 11/21/2020 at 11:42 PM, MariuszJo said:

I've seen that pull request for this in ticket AR-352. However, I am still experiencing change of the MAC address on every reboot Nano Pi NEO with "Armbian 20.08.1 Bionic with Linux 5.8.5-sunxi". Is this a known problem?

 

Is this a fresh flash or upgrade from previous version?

[Gord_W]

Hi,

I'm also using a nanopi neo and getting a new MAC address on every reboot.  I used a fresh install of Buster today (Dec. 1) and this has the problem.  I also changed to the nightly build Armbian 21.02.0-trunk.5 Buster with Linux 5.9.11-sunxi and that too has the same problem.

Gord_W

 

Edited December 1, 2020 by Gord_W
clarity

[MariuszJo]

On 11/23/2020 at 6:00 PM, TRS-80 said:

Hi @MariuszJo, and welcome to the forums.

 

 

Is this a fresh flash or upgrade from previous version?

Hello @TRS-80 and sorry for late reply. For some unknown reason I've missed your message.

I've just tested it with the latest stable "Armbian 20.11 Bionic with Linux 5.8.16-sunxi". This is a fresh flash. 

 

@Gord_W

As a workaround I am currently running those commands to set fixed MAC address with Network Manager CLI:

 

CONNECTION="$(nmcli -f UUID,ACTIVE,DEVICE,TYPE connection show --active | tail -n1)"
UUID=$(awk -F" " '/ethernet/ {print $1}' <<< "${CONNECTION}")

nmcli connection modify $UUID ethernet.cloned-mac-address D2:E6:90:1D:C8:18 
nmcli connection modify $UUID -ethernet.mac-address ""

 

Edited December 7, 2020 by MariuszJo

[Gord_W]

Thanks for the workaround.  I've tried out DietPi and it doesn't have the problem of changing MAC address.  I'm not sure if their image is built on Armbian or directly on Debian for NanoPi Neo H3, but anyway is seems to be light and works.

[TRS-80]

17 hours ago, MariuszJo said:

Hello @TRS-80 and sorry for late reply. For some unknown reason I've missed your message.

 

Well, at the time I was in IRC and speaking directly to one of devs and that was what he had told me to ask you, of course by now it's all been forgotten but hopefully someone sees this thread and can pick up and go from there.

 

I suspect some issue with resolvconf... or...?  Anyway I will ping @lanefu here as he was the one I was discussing it with at the time (~ 2 weeks ago, when I had asked you the last question).

 

17 hours ago, MariuszJo said:

I've just tested it with the latest stable "Armbian 20.11 Bionic with Linux 5.8.16-sunxi". This is a fresh flash. 

 

And...?  The problem persists?  Or not?  You did not clearly state one way or the other. 

 

Also, thanks for posting a workaround, for the time being. 

 

19 minutes ago, Gord_W said:

DietPi

 

I played with it briefly some time back (on an RPi) and found it quite "weird" as they seem to have "their own way" of doing lots of OS level things whereas Armbian is much closer to "normal" Debian.  Armbian's approach I thought was very well thought out from an architectural / maintenance viewpoint.

 

To be clear, while annoying, this is not simply about my personal preference, but rather making note that maintaining all that "special sauce" (which is largely re-inventing wheels) is eventually going to become a never ending maintenance burden, which can become exhausting, and thus less sustainable, long term.

 

Also, from an adoption standpoint (especially of experienced users / devs, who will need to become the backbone of the community, if it is to survive/thrive) I dunno, I am just not interested in learning (anyone's) "special / different" way of doing things.  That was probably the biggest turn off for me about it, personally, and I can't help but imagine that others might reach similar conclusion.

 

21 minutes ago, Gord_W said:

I'm not sure if their image is built on Armbian or directly on Debian

 

I am not sure either; so I searched briefly just now, and noticed they don't even link to their source code from their home page (I had to search around the Internet to find it).  But from their GitHub I could not tell at a glance either, and I don't have time to go digging through their sources right now to try and figure it out.  To their credit, they do at least list Armbian as well as Debian down toward the bottom in the 3rd Party Sources/Credits list (on GitHub, not their home page).

 

I am only very lightly familiar with the project, so I don't know how much of our stuff they actually use.  I do know that the main work that Armbian devs focus on are the most difficult, low level (hardware/kernel) issues.  And therefore I suspect a lot of these other distros are piggybacking off of that (not glorious, however very important) work.  Therefore in my view, why use any of downstream distros?  But I think the same way on x86, where I am also a vanilla Debian user.  However of course, many of the downstream distros from Debian have become very popular (which is something I don't understand, either).  Anyway...

[MariuszJo]

On 12/8/2020 at 6:12 PM, TRS-80 said:

And...?  The problem persists?  Or not?  You did not clearly state one way or the other. 

You're right, it may have not been clear . The problem persists. 

[Werner]

Tried to set a fixed random mac in /boot/armbianEnv.txt ?

 

ethaddr=XX:XX:XX:XX:XX:XX

 

[MariuszJo]

17 hours ago, Werner said:

Tried to set a fixed random mac in /boot/armbianEnv.txt ?

No. I will try and let you know if this helps. 

[Peter Sauer]

Same problem with a NanoPi Neo and Buster 20.11.3.

 

An entry in /boot/armbianEnv.txt failed - but old school interface settings worked for me.

 

Bevor I tried nmcli commands.

 

[MariuszJo]

@WernerI've added "ethaddr=XX:XX:XX:XX:XX:XX" with proper MAC set to /boot/armbianEnv.txt  in clean installation of "Armbian_20.11_Nanopineo_bionic_current_5.8.16".
Unfortunately, MAC address is still changed on every reboot.

[Werner]

7 hours ago, MariuszJo said:

Unfortunately, MAC address is still changed on every reboot.

Then try this:

13 hours ago, Peter Sauer said:

but old school interface settings worked for me.

 

[MariuszJo]

Hi @Werner,

thanks for your suggestion. For me it is currently not about finding a solution, because I have a working workaround with nmcli which I have described earlier. 
I wanted to find out if others have the same issue and then maybe reopen ticket AR-352 or open a new one. Of course finding a right solution to fix it in Armbian would be also nice, but I feel it is beyond my knowledge .

 

[Gord_W]

8 minutes ago, MariuszJo said:

 

I wanted to find out if others have the same issue .

 

As I said earlier this month, I had the same problem with NanoPi Neo.

[MariuszJo]

10 minutes ago, Gord_W said:

As I said earlier this month, I had the same problem with NanoPi Neo.

That's right. I forgot about it. I've tried to open new issue on https://armbian.atlassian.net/, but it seems to require some authorization I do not have. I couldn't find a right project in Github (https://github.com/armbian) to report the issue either.

Maybe someone could point me to the right place to report it?

 

[Igor]

16 minutes ago, MariuszJo said:

but it seems to require some authorization I do not have

That is correct. We use Jira to track development progress and only developers, those who agree to contribute to this project, to the open source, are allowed to open bugs and tasks ... which they/we are planning to work on. Sadly public contribution is too small to have a group of full timers that would catch bugs you find and wishes you have. Why we would need to cover from private resources all of the development, while you will just use it and complain about?

 

Even we would allow you to file bugs, we are fully (over)loaded, for years to come and nobody will read them.

Solving those problems first, then bugs.

[MariuszJo]

Hi @Igor,

First of all - I think you are doing a great job with Armbian. That's why I've decided to use it and it is also a reason I've wrote the message on this forum  . Thank you for that. 
I am the code contributor to a couple of open source projects myself and I've always treated creating a bug report as a contribution to the project as well. For me it was often a good starting point in the project. I was able to find out how to gather more information about the issue and learn about the project on the way. Later on it was easier for me to start with the coding.

I am sorry if my posts sound like complaining about development work - it wasn't my intention. I don't think you should cover development you don't need from your private resources.

I still think it would be nice to be able to create a ticket even if you would not prioritize it and decide to close it when it become stale. It is because I could track it e.g. to find out if other users have the same problem. Even if I would not be able to contribute a solution, I could close it one day if I will find out it is working again. 

I believe this forum, at least partially, fulfills that, so it is also fine. I just had an impression I should report it somewhere, if it is confirmed, so it is more visible for people working on the project. It was all in good faith . 

 

Anyway, sorry for offtopic, but you've asked a question, so I had to answer ;). 

Keep up the good work!

 

[Igor]

7 hours ago, MariuszJo said:

I've always treated creating a bug report as a contribution to the project as well.

If we would be behind a clearly rounded Java application called Armbian and you will be filing bugs for its functioning. Absolutely. 

 

Linux kernel is a work of lets say 5.000 people. User space is covered by another 5.000 people. And you are filing bugs all over this place regardless if we have something to do with it or not. I understand that most people don't know that, but we have survive this battle. Actually you are asking for expensive R&D and support services all the time. Usually "customers" can't just bug developers directly. They reach out to support service and support service is talking with developers and pay attention to not overload and kill them.

 

You want that a few people solve everything everywhere. That is the actual content of public "bug reports" scattered around this forum, GitHub tickets, Jira, IRC ... and if we would raise lets say 1 mio USD to hire help, we would not be able to clear out what is filed until now.

 

7 hours ago, MariuszJo said:

I don't think you should cover development you don't need from your private resources.

 

Sadly projects like this are covered mainly by their contributors. Its our donation to the open source - which has limits. Even we don't want to deal with your bug, we still invest around 3-4k EUR of work every day for other bugs, tasks and support projects. Its our private cost almost entirely. There is some help from the industry, there are some donations. We can run this place ad free, we cover fixed costs, but biggest costs, R&D and supporting you remains on our shoulder.  We are not like most of Linux distros out there that only distribute 3rd party work. We create value. A lot of it.

 

7 hours ago, MariuszJo said:

I still think it would be nice to be able to create a ticket

 

People that chose to contribute are already under big stress and allowing users to open tickets means just allowing more pressure on them. Armbian is not a commercial product, we rely on your donation. If you don't cover what you get, we have to stop you at some point. Or allow that we are eaten alive.

Personally I think contributors well being, their safety is more important than "customers" satisfaction. Armbian is assembled from "as is" software which we can't push to the perfection with  1/1000 of needed resources.

 

I know most people and you especially have good intentions, but on this side it is and it will always be way too small team. We can't change that. Only you can. If you wanna work with us for publicly available software and research & solve this topic - with any speed you want - send me email for Jira access. Or if you have better ideas how to do the impossible.

 

That's why.

[Gord_W]

13 hours ago, MariuszJo said:

I believe this forum, at least partially, fulfills that, so it is also fine. I just had an impression I should report it somewhere, if it is confirmed, so it is more visible for people working on the project. It was all in good faith . 

I too thought that it was important to file bug reports when things aren't working.  Open source is always a sort of beta test and one way people with less skills than developers could contribute is identifying problems, providing details, answering questions and testing solutions.

 

No one is "demanding" anything gets fixed - this is open source.  It is important, though, that known problems are identified and confirmed by other people so other users that run into the same problem in the future will know and can act accordingly.

 

[Igor]

25 minutes ago, Gord_W said:

No one is "demanding" anything gets fixed - this is open source. 

There are people that comes and demand support and are offensive in this. Luckily those are rare events, but every now and then someone steps on our nerves or directly insulting us because we don't do something. Do we need this?

 

Then there is constant flow of reports on this forum, private messages, IRC, emails are coming all the time into our direction. Rare are who dares to directly demands, but constant pressure is very real.

Luckily we all have jobs, where we can rest a little.

[TRS-80]

52 minutes ago, Gord_W said:

No one is "demanding" anything gets fixed

 

Well, you guys here in this thread do seem to "get it" and I for one certainly appreciate that.  And in fairness, probably even the majority do.  However, and unfortunately, a few others do not.  And that just wears on Igor after a while.  He is only a human bean like the rest of us, after all.

 

In fact that is one of main reasons I try and help out around forums, to try and relieve some pressure from devs by not only taking care of some "low hanging fruit" type issues, but also some times act as some sort of buffer.  Because I see both sides of the issue.  And I really worry that Igor will have enough one day and quit.  I have seen it too many times over the years in F/LOSS projects.  And then, well, "this is why we can't have nice things." 

 

If anyone would like to assist me in this task, it would be enough to simply scan forum's "All Activity" stream and reply anywhere you think you can help.  Currently I am doing this at level of part time job (many hours every day) however I have the luxury of taking a break from regular "work" at the moment.  All of that comes to an end after the first of the year however as I need to go back to making money...  However my hope is a few other people will step up and "with many hands make light work" but that is perhaps only wishful thinking on my part...

 

So yes, the forums (to my understanding) were designed as a sort of middle ground, "bug reporting" area, and place where users can help one another until devs can get around to particular issues.  Therefore please continue to do those things.

 

I guess all we can do is continue to try and set realistic expectations in the meantime.  I have for instance seen threads go un-answered for months, years even before achieving resolution.  And a lot of people (especially nowadays) seem to have some sort of "instant gratification" mentality.  Not you guys.  Just talking in general.

 

Edited December 18, 2020 by TRS-80

[CeeGO]

On 12/12/2020 at 10:42 PM, Werner said:

Tried to set a fixed random mac in /boot/armbianEnv.txt ?

 

ethaddr=XX:XX:XX:XX:XX:XX

 

 

On 6/30/2020 at 9:08 AM, xwiggen said:

yes this is an issue with newest downloadable buster image, been meaning to fix that but no time yet at hand.

workaround for classic specification (/etc/network/interfaces)

auto eth0
iface eth0 inet dhcp
        hwaddress ether 12:34:56:78:9A:BC

 

or set dhcp-client-identifier 12:34:56:78:9A:BC in dhclient.conf (https://linux.die.net/man/5/dhclient.conf)

 

 

Thanks for the work-arounds posted here.

 

I'm using a NanoPi Neo and the latest "bionic" image. This issue is still a problem. Changing dhclient.conf and armbianEnv.txt did not work. Using /etc/network/interfaces was the only way I could get it to work.

 

[Bucking Horn]

I am using a NanoPi NEO 1.4 and also observed MAC changing with each reboot. 
Linux npi-neo-1 5.10.21-sunxi #21.02.3 SMP Mon Mar 8 00:28:04 UTC 2021 armv7l GNU/Linux

While I was successful configuring `/etc/network/interfaces` (`armbianEnv.txt` didn't work, didn't try `dhclient.conf`), I wasn't quite satisfied by the results.

Spoiler

The MAC was set alright, but I noticed that `ip route` returned uncommon results:

~$ ip route
default via 192.168.0.1 dev eth0 proto dhcp metric 100
default via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.32 metric 202
169.254.0.0/16 dev eth0  scope link  metric 1000 
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.28 metric 100
192.168.0.0/24 dev eth0 proto dhcp scope link src 192.168.0.32 metric 202

The link-local is likely appearing due to DHCP not recognizing the new MAC.
But the other routes seemed to be duplicated, likely because the initial random MAC was been substituted by the one from `interfaces` at some stage during boot. 

 

Also, there were too many IPv6 addresses for my IPv6 local only network. 
Most notably, RFC7217 addresses should have replaced EUI64 ones, which they didn't:

~$ ip -6 address show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fd08:ff::40ac:dcff:feba:dcaf/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 6989sec preferred_lft 3389sec
    inet6 fd08:ff::cef:c770:568b:f3db/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 6998sec preferred_lft 3398sec
    inet6 fd08:ff::5780:7e91:830:17e/64 scope global dynamic noprefixroute
       valid_lft 7001sec preferred_lft 3401sec
    inet6 fe80::40ac:dcff:feba:dcaf/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

 

I thus looked for a different solution and stumbled over
https://epsilonrt.fr/2018/03/corriger-une-adresse-mac-aleatoire-dans-armbian-sur-nanopi/

 

The solution suggested by that three year old post doesn't work with my kernel.

But as it turned out, the analysis for the underlying problem was spot-on.

 

That prompted me to create a custom device tree overlay as `nanopi-neo-stable-mac.dts` as follows:

/dts-v1/;
/plugin/;

/ {
    compatible = "allwinner,sun8i-h3";

    /* 
     * uboot tries to write a MAC address from ${mac_node}
     * to the device tree at 'local-mac-address' within 'ethernet0'
     *   fdt set ethernet0 local-mac-address ${mac_node}
     * This obviously doesn't work if the device tree does not match the  
     * expected structure, resulting in the kernel creating a random MAC.
     * 
     * This overlay adjusts the device tree to accept uboot's MAC address 
     * by adding 
     * - 'ethernet0' alias for symbol '/soc/ethernet@1c30000'
     *   (or change to whatever path your existing symbol 'emac' points to)
     * - 'local-mac-address' to structure at 'emac'
     * 
     * Tested to work on a NanoPi NEO 1.4 - adjust for other devices as required
     */

    fragment@0 {
        target-path = "/aliases";
        __overlay__ {
            ethernet0 = "/soc/ethernet@1c30000";
        };
    };

    fragment@1 {
        target = <&emac>;
        __overlay__ {
            local-mac-address = [00 00 00 00 00 00];
        };
    };
};

 

This custom overlay can be compiled with
sudo armbian-add-overlay nanopi-neo-stable-mac.dts  

 

You may verify that `/boot/armbianEnv.txt` has been expanded by a new user_overlays option like:
user_overlays=nanopi-neo-stable-mac

 

After a reboot, a stable MAC will be used (likely starting with `02:81`)

 

You may verify that `local-mac-address` has indeed been set by running:
sudo dtc -qq -I fs /proc/device-tree | grep local-mac-address

 

This should return something like:
    local-mac-address = [ 02 81 01 ba dc af ];

 

My initial complaints were also gone.

Spoiler

`ip route` is back to normal:

default via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.33 metric 202
192.168.0.0/24 dev eth0 proto dhcp scope link src 192.168.0.33 metric 202

And the number of IPv6 addresses is also down to normal levels:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fd08:ff::c4d9:3227:374:5655/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 7169sec preferred_lft 3569sec
    inet6 fe80::47ad:9e7d:46ee:7c00/64 scope link
       valid_lft forever preferred_lft forever

 

 

What remains to be verified is whether that stable MAC is specific for that device or identical across multiple devices of the same type.
As I only have that one device, I cannot test this.

 

It would be important if you would run multiple NanoPi NEOs on the same link.

 

Maybe a developer can shed some light on how uboot acquires that MAC address?

 

Edited March 25, 2021 by Bucking Horn

[bfgmatik]

Thanks for solving this problem. I will test this as soon as I get back to my workshop next week.

 

I looked in sources of u-boot v2020.10 and it seems that u-boot calculates the MAC address based on CPU sid registers (in function setup_environment(), file board/sunxi/board.c by calling sunxi_get_sid() and making a CRC32 calculation on received unique register values. So basically this what we need.

 

I'm currently working on a project utilising NanoPi Duo2 and this board has the same problem with changing mac address. And for some other boards like NanoPi M1, ethernet0 alias is correctly defined in dts files.

 

 

[smersh]

Hi,

If it's still actual, I can confirm that with the Bucking Horn's `nanopi-neo-stable-mac.dts` the MAC is fixed and is specific for the device.

Thanks!

NJ

[c332030]

In 2023, the problem still exists

[IDN]

Hello, i am wondering if this fix still works, and if it is possible to implement it on the NanoPC T6 ? 
Im having the issue that both the LAN ports on it gets random MAC addresses after reboot and thus cannot use it for what i need.
Been looking for a solution for a while when i ran into this thread. 

IF this still works, i would love some help modifying it to be used in the T6.

Hope to get answers, thanks!

-IDN