Ether address in armbianEnv.txt on PineA64

[Andro]

Running Armbian Ubuntu Xenial 16.04 on a PineA64, legacy kernel 3.10.105-pine64. Why is it necessary or desirable to put the variable 'ethaddr' in armbianEnv.txt?

 

I thought the hardware mac address would be detected by the kernel. Perhaps not?

[tkaiser]

Can you please provide output from

sudo armbianmonitor -u
cat /sys/class/net/eth0/address
grep ethaddr /boot/armbianEnv.txt

@Igor: I see patches up to 3.10.107 in the repo but get only 3.10.105 from apt.armbian.com. Why?

[zador.blood.stained]

On most of these devices there is no such thing as "hardware MAC address". The best alternative on sunxi devices is MAC address based on the SoC serial number, but AFAIK it's not implemented on the legacy kernel because it is maintained just enough to work, and most development efforts are focused on the mainline kernel.

[Andro]

57 minutes ago, tkaiser said:

Can you please provide output from

sudo armbianmonitor -u
cat /sys/class/net/eth0/address
grep ethaddr /boot/armbianEnv.txt

 

# armbianmonitor -u:

http://sprunge.us/jUbU

 

# cat /sys/class/net/eth0/address

46:d5:67:c2:29:8e

 

# grep ethaddr /boot/armbianEnv.txt
ethaddr=46:d5:67:c2:29:8e

 

So the system certainly picks up the assigned MAC address just fine.

 

The question arose for me because I am making clones of cards to run multiple board systems on one LAN, so it appears I have to edit armbianEnv.txt for each system individually and provide a different MAC for each board by hand. That's not onerous, but just another step that needs to be done.

 

 

[Andro]

32 minutes ago, zador.blood.stained said:

On most of these devices there is no such thing as "hardware MAC address". 

This I did not know, so that's very useful information. I had always thought every ethernet NIC had a burned in MAC address, but now I see that's not the case on these small boards. Thanks!

[tkaiser]

43 minutes ago, zador.blood.stained said:

The best alternative on sunxi devices is MAC address based on the SoC serial number, but AFAIK it's not implemented on the legacy kernel

 

Well, it should work in the meantime: https://github.com/longsleep/linux-pine64/commit/c7c5a1f33949da6844a389354bed2c99c6240969

 

13 minutes ago, Andro said:

So the system certainly picks up the assigned MAC address just fine.

 

Well, on first boot it was set to this 'eth0 Link encap:Ethernet HWaddr 46:d5:67:c2:29:8e' and this has been written to armbianEnv.txt then. You might want to try to remove the line so kernel cmdline reads again 'mac_addr= ' and report back what happens (when booting the image two times on two different boards). Maybe we can remove this from our firstrun script already.

 

[Igor]

1 hour ago, tkaiser said:

@Igor: I see patches up to 3.10.107 in the repo but get only 3.10.105 from apt.armbian.com. Why?

No particular reason. I usually update main repo at major release or if there is a critical bugfix. I guess this one does not need much extra testing ... ASAP.

[tkaiser]

5 minutes ago, Igor said:

I usually update main repo at major release or if there is a critical bugfix. I guess this one does not need much extra testing ... ASAP.

 

Hmm... Would it be possible to update beta and main apt repo partially? I think the purpose of the various LTS kernels we use is to provide security/important fixes so it would be great once something like a 3.10.105 --> 3.10.106 update happens that this gets reflected in beta apt repo and after one week without complaints moves to apt.armbian.com.

 

Somehow possible with reasonable efforts?

[tkaiser]

On 8.9.2017 at 4:59 PM, tkaiser said:

Well, it should work in the meantime: https://github.com/longsleep/linux-pine64/commit/c7c5a1f33949da6844a389354bed2c99c6240969

 

It does. Same installation booted without ethaddr / mac_addr=${ethaddr} defined. Booted 3 times on 1 Pine64+, then on another: http://sprunge.us/Ngfd

eth0      Link encap:Ethernet  HWaddr 56:8a:0f:5d:71:2e
vs.
eth0      Link encap:Ethernet  HWaddr 62:04:7f:58:00:8a

IP address remained the same since configured statically.