The Mac Address Would Not Change on Debian, nor Gentoo

[MarkHaysHarris777]

I ran into a very frustrating yet interesting problem last night when I tried to place two of my PineA64 boards on the same ethernet switch in preparation for the GbE testing I plan to do tomorrow.

Both of my machines had a VERY persistently stubborn mac address ( which belongs to longsleep ):
36:c9:e3:f1:b8:05

I am wondering now how many folks having ethernet problems don't really have an ethernet problem, they just don't have unique mac addresses on their network from the Pine Boards ??  (arp cache nightmare)

Anyway, I tried repeatedly to change the mac addresses of both machines... and they would NOT change... neither of them... for almost four hours.

I changed the mac address in  /boot/uEnv.txt  , powered off and then did a cold boot.  (this on both machines)  but when the boot finished  both machines still had address  36:c9:e3:f1:b8:05

Believe it or not what I did to correct this was just be persistent... I started waiting longer between poweroff and cold boot...  eventually the new address finally 'took' on both machines.  When the address finally 'took' on both machines, both machines finally had the correct address in all four primary places:
/boot/uEnv.txt
/proc/cmdline
/sys/class/net/eth0/address
ifconfig

I really feel strongly that this needs to be changed. All Pine Boards need to have an automatic persistent unique mac address on the ethernet port;  like any other IP machine interface. Or, there needs to be a very consistent way to set the persistent mac address easily so that multiple Pine Boards on the same switch are guaranteed to have unique mac addys;  essential for Pine-Nut  clusters !

edit: PS. I suspect that the mac address of choice has something to do with this as well... it may be that I just happened upon a prefix that would work... but took some trial and guessing. But, its looking like the mac address can not be fully ransomized.

[martinayotte]

Effectively, some drivers validate that first half of the Mac correspond to Manufacturer ID, and only the second half can be randomnized.
I recall for having facing that on OrangePi board with the Realtek driver.

[longsleep]

Effectively, some drivers validate that first half of the Mac correspond to Manufacturer ID, and only the second half can be randomnized.
I recall for having facing that on OrangePi board with the Realtek driver.

I will look into it asap.

[grobbs]

I am fighting this right now. I tried to change the MAC address and then Pine64 would not boot
I tried erasing the line from uEnv.txt and it assigned the same one: 36:c9:e3:f1:b8:05.

---

The board appears to be crashing (soft-lock):

[ OK ] Started Increase datagram queue length.
[ 13.682606] systemd[1]: Started Increase datagram queue length.
[ 13.895106] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 39.197658] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:1:30]
[ 39.209967] Modules linked in: cfg80211(+)
[ 39.219715]
[ 39.226370] CPU: 0 PID: 30 Comm: kworker/0:1 Not tainted 3.10.102-2-pine64-longsleep #66
[ 39.240276] Workqueue: events start_work
[ 39.249567] task: ffffffc039b56f80 ti: ffffffc039b58000 task.ti: ffffffc039b58000
[ 39.262840] PC is at __do_softirq+0xb4/0x2d8
[ 39.272563] LR is at __do_softirq+0x30/0x2d8
[ 39.282228] pc : [<ffffffc0000b5f78>] lr : [<ffffffc0000b5ef4>] pstate: 40000145
[ 39.295408] sp : ffffffc039b5b910

All I did was change the MAC address in uEnv.txt!

[MarkHaysHarris777]

I am fighting this right now. I tried to change the MAC address and then Pine64 would not boot
I tried erasing the line from uEnv.txt and it assigned the same one: 36:c9:e3:f1:b8:05.

---

The board appears to be crashing (soft-lock):

<snip>

All I did was change the MAC address in uEnv.txt!

The mac address needs to be :  00:06:dc:xx:xx:xx

The first three must be 00:06:dc   ,  the manufacturer id.  The last three can be randomized;

[grobbs]

Thanks for your reply. The image I had was using the older kernel that couldn't generate a random MAC. Updating the kernel solved the issue.