No static Mac address since v9.7.1

temp · 31 May 2025 14:41

Do I need to uninstall anything before??

I have done this before

iface='eth1'
mac=$(ip -br l | mawk -v "iface=$iface" '$1 == iface {print $3}')
sudo mkdir -p /etc/systemd/system/networking.service.d
echo -e "[Service]\nExecStartPre=/sbin/ip l set dev $iface address $mac" | sudo tee /etc/systemd/system/networking.service.d/set_mac.conf

@MichaIng

MichaIng · 31 May 2025 18:34

Ah yeah, disable that one for now:

sudo mv /etc/systemd/system/networking.service.d /etc/systemd/system/networking.service.d.bak

temp · 31 May 2025 20:08

Looks good on my system

MichaIng · 1 June 2025 01:28

Great, it should apply MACs which are close to each other, differing only in the last digit.

MichaIng · 5 June 2025 17:08

@temp is it an R5S or R5C in your case?

And I had a typo in my commands, “images” instead of “image”, so without correcting that, the download (and installation) would have failed. Did you fix that to have the kernel package downloaded correctly?

temp · 5 June 2025 18:45

Is a r5s

I get only this

W: Possible missing firmware /lib/firmware/rtl_nic/rtl8126a-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rockchip/dptx.bin for module rockchipdrm

And yes I correct images to image

MichaIng · 6 June 2025 00:18

Okay, still need one with R5C to test. On GitHub however, we have a case where the kernel with this patch fails to boot, just no idea yet why, or how it can even be (as the patch is pretty uncritical, even if it would not work).

You can ignore this. The armbian-firmware package misses a few firmware binaries for certain network drivers, while all network drivers are added to the initramfs, regardless which ones are really used by the device. So it warns if any firmware binary for any network driver is missing.

temp · 10 June 2025 16:24

I see another issue now …my eth0, interface has no ipv6 address anymore

Checked it today now I have a ipv6 address

temp · 29 June 2025 06:19

@MichaIng now it’s back I didn’t get any stable Mac Adress since I applied the update dietpi v9.14.2.

Can I go back with no risk to the original solution? This here: No static Mac address since v9.7.1 - #5 by temp

Joulinar · 29 June 2025 07:31

Should be possible, just give it a try

MichaIng · 29 June 2025 13:47

Can you show the kernel build you use?

uname -a
dpkg -l | grep linux-image-current-rockchip64

Works well for me:

root@NanoPiR5S:~# uname -a
Linux NanoPiR5S 6.12.34-current-rockchip64 #1 SMP PREEMPT Thu Jun 19 13:32:38 UTC 2025 aarch64 GNU/Linux
root@NanoPiR5S:~# dpkg -l | grep linux-image-current-rockchip64
ii  linux-image-current-rockchip64  25.08.0-trunk-dietpi2          arm64        Armbian Linux current kernel image 6.12.34-current-rockchip64
root@NanoPiR5S:~# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 7a:b8:44:18:54:c4 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 7a:b8:44:18:54:c5 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 7a:b8:44:18:54:c7 brd ff:ff:ff:ff:ff:ff

That the MAC addresses differ in the last digit only is the indicator. U-Boot generates these, the first from some hardware identifier, the second by inverting the last bit of the last hex digit, and with our patch, also the 3rd by inverting the second last hex digit. The kernel also needed a patch to contain device tree aliases for the two 2.5 Gbit ports. Mainline Linux assigns only one for the 1 Gbit port, hence this was the only one with a static MAC.

Just in case, you did recognize that eth1 and eth2 switched place, and either accepted to have configs adjusted automatically, or done by yourself?

temp · 29 June 2025 20:11

root@pihole:~# uname -a
Linux pihole 6.12.34-current-rockchip64 #1 SMP PREEMPT Thu Jun 19 13:32:38 UTC 2025 aarch64 GNU/Linux
root@pihole:~# dpkg -l | grep linux-image-current-rockchip64
ii  linux-image-current-rockchip64  25.08.0-trunk-dietpi2               arm64        Armbian Linux current kernel image 6.12.34-current-rockchip64
root@pihole:~# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 76:e4:b5:41:b9:7f brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 66:e3:ba:ae:b2:d8 brd ff:ff:ff:ff:ff:ff
4: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether e8:fb:1c:35:5c:39 brd ff:ff:ff:ff:ff:ff
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 500
    link/none
6: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none
7: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 36:98:24:ea:bc:57 brd ff:ff:ff:ff:ff:ff
8: veth67e84e9@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default
    link/ether 56:28:d6:44:f2:8e brd ff:ff:ff:ff:ff:ff link-netnsid 0

MichaIng · 30 June 2025 00:11

Ohh, it is an R5C in your case, isn’t it? Because you have 2 Ethernet interfaces only. Or is one missing unexpectedly?

cat /proc/device-tree/model

If it is an R5C, and you had static MAC addresses when using the testing kernel build, that would be pretty good news. One other tester had boot issues with that kernel, and it is the one of the R5S/R5C/R6S/R6C that I do not have here for testing yet. So I did not release the static MAC address kernel patch for the R5C yet.

temp · 30 June 2025 04:33

I have a r5c I thought it’s an s die to the fact I bought a s via Amazon but it was wrong declared

So I need to re apply your patch or do the old way?

MichaIng · 30 June 2025 16:34

As long as you do not need the board features of the R5S all good . Okay that explains it. Let me trigger a kernel build with the patch for R5C included again. Looks like in the other case, the boot issue was not related to it then. I was already wondering, because I could not find the issue, and even if it was not functional, that kind of patch should have never caused boot issues, but worst case the Ethernet ports would not have been functional or so.

Build running: Armbian · MichaIng/DietPi@3b48f02 · GitHub
Once and if this has successfully finished in roughly 1 hour:

cd /tmp
wget https://dietpi.com/downloads/binaries/testing/linux-{dtb,image}-current-rockchip64.deb
dpkg -i linux-{dtb,image}-current-rockchip64.deb

If this works for you, I will push that build to our APT server.

temp · 1 July 2025 19:49

Looks good to me

MichaIng · 1 July 2025 20:10

Booting and MAC addresses static, both differing in last hex digit only?

temp · 1 July 2025 20:50

Yes perfomed 80-90 reboots over the day

MichaIng · 1 July 2025 22:06

Okay, I hope the reboots were needed for other reasons . Anyway great news, I will push the kernel to our repo.

temp · 2 July 2025 03:49

Haha the reboots were forced from my side for testing:)