TonyB.ca

Greetings All, If I run one of the Friendly distributions, they use the correct (physical) MAC address. My 3 are as follows: 80:34:28:79:4e:5c 80:34:28:79:2e:07 80:34:28:79:20:31 From this we can tell that FriendlyElec uses "80:34:28" as their vendor code. The remaining 3 digits compose the individual NIC address. Thanks for providing the script to work around the issue. It does what it needs to do, but it still raises the question as to why this is necessary. The FriendlyElec build does not require that we do this, so it would be great to have a base code fix. At some point I will try simply deleting the directory containing the script to see what happens ( - unless somebody else gets there first - 🙂 - ). For now, this script does what is needed ... bracka@NanoPi-NEO3b:/etc/NetworkManager/system-connections$ hostnamectl Static hostname: NanoPi-NEO3b Icon name: computer Machine ID: f86b967515a04b7aa4ee086b7ee8f50b Boot ID: 7d724c0ff2a544f7959641728cacfe16 Operating System: Ubuntu 20.04.6 LTS Kernel: Linux 5.15.78 Architecture: arm64 bracka@NanoPi-NEO3b:/etc/NetworkManager/system-connections$ ls -al total 8 drwxr-xr-x 2 root root 4096 Nov 26 2021 . drwxr-xr-x 7 root root 4096 Jun 13 20:55 .. Regards & Thank You, Tony

Hi All, Again, the running operating system even reports back the physical MAC address. Something is overriding it, but finding out what and where is the challenge. My guess is that it is common code that is shared with the NEOs and possibly NEO2s which do not have a hard MAC address. These are line numbers from the same output. The FriendlyElec build of the same kernel does not have this problem. Maybe we need to look into armbianmonitor to find out the difference between the 2 sections of output as a potential starting point? This is a single output produced by running this program, and seems to be reporting the same interface, so SOMETHING already knows the physical MAC address. From my initial post: $ armbianmonitor -U ... 730 ### ip addr: 731 732 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 733 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 734 inet XXX.XXX.0.1/8 scope host lo 735 valid_lft forever preferred_lft forever 736 inet6 ::1/128 scope host 737 valid_lft forever preferred_lft forever 738 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 739 link/ether 9a:84:df:28:e1:3e brd ff:ff:ff:ff:ff:ff ... 1525 ### ip addr: 1526 1527 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 1528 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 1529 inet XXX.XXX.0.1/8 scope host lo 1530 valid_lft forever preferred_lft forever 1531 inet6 ::1/128 scope host 1532 valid_lft forever preferred_lft forever 1533 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 1534 link/ether c2:1f:b3:b0:d2:41 brd ff:ff:ff:ff:ff:ff

Hi KaoDome, I downloaded the minimal release from FriendlyElec and it picks up the physical MAC address just fine. I have built a few minimal release images, but have not had a chance yet to test them out since some morons hacked by test lab and decided to encrypt/ransom my NAS and a bunch of dev VMware servers. So much for easy passwords in a test lab (lesson learned) ... no big deal as all the data is either trash or replaceable, and it was due for a redesign anyway. The FriendlyElec build is older, but uses the correct MAC address. I will post details once my network is fully back on line. If you look at my post, I explain what I am seeing. If we can determine where to look, I am certain that the change is obvious as these are both Debian/Ubuntu releases.

Because this thread is so dated, I created a new posting with more details. Ubuntu 20.04.6 LTS does not have the same problem. see:

Further comment: I built the latest "bookworm/edge" image and it has the same problem. Can anybody point me at which modules set this or give me ideas as to how to locate it and I'll try my hand at correcting it? (... or try finding what Ubuntu did to fix it) bracka@nanopi-neo3:~$ hostnamectl Static hostname: nanopi-neo3 Icon name: computer Machine ID: e0dd9ba08bec458e97d14aa2a8797a5e Boot ID: 04b5eb118e9b4fb8a876b4ed81342106 Operating System: Armbian 23.08.0-trunk bookworm Kernel: Linux 6.3.4-rockchip64 Architecture: arm64 bracka@nanopi-neo3:~$ sudo ifconfig -a end0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.196 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::dc32:47a9:6da5:4074 prefixlen 64 scopeid 0x20<link> ether c2:1f:b3:b0:d2:41 txqueuelen 1000 (Ethernet) RX packets 645931 bytes 759294079 (724.1 MiB) RX errors 0 dropped 148 overruns 0 frame 0 TX packets 144665 bytes 89492195 (85.3 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 51 . . . I have also built the latest "jammy" release and it has the same issue: Welcome to Armbian 23.02.2 Jammy with bleeding edge Linux 6.1.11-rockchip64 bracka@nanopi-neo3:~$ hostnamectl Static hostname: nanopi-neo3 Icon name: computer Machine ID: 419c0895553e4efe9795e6f0899a794e Boot ID: 89aff8b2899c43d0aa16b0c245556b4d Operating System: Ubuntu 22.04.2 LTS Kernel: Linux 6.1.11-rockchip64 Architecture: arm64 bracka@nanopi-neo3:~$ ifconfig -a eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.196 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::350b:a860:b0a1:80b9 prefixlen 64 scopeid 0x20<link> ether c2:1f:b3:b0:d2:41 txqueuelen 1000 (Ethernet) RX packets 109 bytes 11465 (11.4 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 91 bytes 11480 (11.4 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 51 -- -- -- So far, this release from the "Friendly" site does pick up the hardware MAC and use it. Welcome to Ubuntu 20.04.6 LTS (GNU/Linux 5.15.78 aarch64) bracka@NanoPi-NEO3-2:~$ hostnamectl Static hostname: NanoPi-NEO3-2 Icon name: computer Machine ID: 493a472b58ef4baeaa0a4962766bd9a6 Boot ID: cf237517e7ad4aa7a89a18a30972b560 Operating System: Ubuntu 20.04.6 LTS Kernel: Linux 5.15.78 Architecture: arm64 bracka@NanoPi-NEO3-2:~$ ifconfig -a eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.197 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::8234:28ff:fe79:2031 prefixlen 64 scopeid 0x20<link> ether 80:34:28:79:20:31 txqueuelen 1000 (Ethernet) RX packets 1137985 bytes 1275043076 (1.2 GB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 118723 bytes 22628010 (22.6 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 37 Regards, Tony

Greetings, I have multiple NanoPi NEO3s on the same subnet. When booting with Ubuntu 20.04.6 LTS they use the physical MAC address when posting to DHCP, but ARMbian seems to create a default (fake) MAC address and uses that instead. Judging by the "armbianmonitor -U" output, ARMbian knows about the physical MAC address, it just doesn't use it. The NEO3 board is listed as supported, but there is another posting dated 2020 that still seems to be unresolved. MAC address c2:1f:b3:b0:d2:41 seems to be a generic (fake) address that is being used. Is there a remedy to allow it to use the actual hardware address with this kernel ? -- -- -- bracka@NanoPi-neo3:~$ hostnamectl Static hostname: NanoPi-neo3 Icon name: computer Machine ID: 7a8f8d11a2be4919bc15a3b60d4bb717 Boot ID: af467481c9054525b978b6a316e61c94 Operating System: Debian GNU/Linux 11 (bullseye) Kernel: Linux 6.1.11-rockchip64 Architecture: arm64 bracka@NanoPi-neo3:~$ sudo ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.196 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::6cf0:52e7:7e44:23f8 prefixlen 64 scopeid 0x20<link> ether c2:1f:b3:b0:d2:41 txqueuelen 1000 (Ethernet) RX packets 1032591 bytes 1165880161 (1.0 GiB) RX errors 0 dropped 471 overruns 0 frame 0 TX packets 303323 bytes 43670515 (41.6 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 51 $ armbianmonitor -U 8 Thu 25 May 2023 09:48:33 PM UTC | NanoPi Neo 3 | 23.02.2 | arm64 | aarch64 | 6.1.11-rockchip64 730 ### ip addr: 731 732 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 733 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 734 inet XXX.XXX.0.1/8 scope host lo 735 valid_lft forever preferred_lft forever 736 inet6 ::1/128 scope host 737 valid_lft forever preferred_lft forever 738 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 739 link/ether 9a:84:df:28:e1:3e brd ff:ff:ff:ff:ff:ff 1316 ### armbian-release: 1317 1318 # PLEASE DO NOT EDIT THIS FILE 1319 BOARD=nanopineo3 1320 BOARD_NAME="NanoPi Neo 3" 1321 BOARDFAMILY=rockchip64 1322 BUILD_REPOSITORY_URL=https://github.com/armbian/build 1323 BUILD_REPOSITORY_COMMIT=1a8daf0 1324 VERSION=23.02.2 1325 LINUXFAMILY=rockchip64 1326 ARCH=arm64 1327 IMAGE_TYPE=stable 1328 BOARD_TYPE=conf 1329 INITRD_ARCH=arm64 1330 KERNEL_IMAGE_TYPE=stable 1331 BRANCH=edge 1525 ### ip addr: 1526 1527 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 1528 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 1529 inet XXX.XXX.0.1/8 scope host lo 1530 valid_lft forever preferred_lft forever 1531 inet6 ::1/128 scope host 1532 valid_lft forever preferred_lft forever 1533 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 1534 link/ether c2:1f:b3:b0:d2:41 brd ff:ff:ff:ff:ff:ff * I am willing to research this if somebody can provide build & submission guidelines.