I see. Thanks! I didn’t know if those were of the same node type (or whatever the correct term is).
So basically I can add local-mac-address = [02 00 00 b3 14 42] (with a suitable MAC address) above the line highlighted below?
And similarly (with a different MAC, of course) above this line?
If so, I’ll submit a pull request to the vyos-bpi-r4 repo. 
I guess that gives me a reason to try out the seemingly pretty straight forward build instructions. 
Yes, I saw that and considered doing so. It wouldn’t help anyone else trying to use these VyOS builds though so I figured that solving it with a patch or two might be more widely useful.
I’m not used to working with patches like these instead of regular git commits essentially as if all changes are cherry-picked. I would normally separate the renaming change from the MAC address change and group them that way, but since I would then patch the same file twice it would probably be more error prone if the first patch was ever removed. @Canoziia Any preference? Logical grouping or one patch per file?
Can you modify this patch (vyos-bpi-r4/patches/BPI-Router-Linux/0001-bpi-r4-eth-name.patch at 6.18-bpi-r4 · KawaiiNetworks/vyos-bpi-r4 · GitHub) and submit a pull request?
Additionally, I seem to have discovered a small issue with the previous patch:
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address MAC VRF MTU S/L Description
----------- ----------------------------------------- ----------------- ------- ----- ----- -------------
eth2 - ca:d6:61:80:5a:0b default 1500 u/u Switch Root
eth3 - 92:f5:fd:5b:90:76 default 1500 u/D SFP+ LAN
eth4 - 5a:a1:f8:ff:00:1d default 1500 u/D SFP+ WAN
eth5 - 02:00:00:b3:14:43 default 1500 u/u 1GbE wan
eth6 - 02:00:00:b3:14:44 default 1500 u/u 1GbE lan1
eth7 - 02:00:00:b3:14:45 default 1500 u/u 1GbE lan2
eth8 - 02:00:00:b3:14:46 default 1500 u/D 1GbE lan3`
The default VyOS eth numbering is 2 higher than I expected (not starting from 0); maybe we can fix this as well.
but this results in same mac for all users of your image…the eeprom-way is more user-friendly as they just set base-mac in eeprom and then it is fixed to their value. And R4 has onboard eeprom, so no need for additional hardware, wiring etc. just set base-mac and count and you’re done. But it is your image 
That’s weird. I run VyOS on a different device already and it starts from eth0 there. 
If you look at the dmesg log, do you see eth0 or eth1 being mentioned?
Also, why are you even changing the existing labels? Don’t they correspond to the labeling on the official case? The labeling you show in that show interfaces output makes it seem like VyOS isn’t using the device tree labels anyway (your descriptions don’t match the device tree patch if I’m interpreting it correctly) so I’m not sure they even matter. Have you confirmed that they even do something?
Is the reason that you hardcoded the MACs that they would otherwise change on every boot and cause issues where the VyOS configuration wouldn’t apply correctly? I imagine that you added that patch after running into an issue of some kind?
Yes, that’s true and it could be an issue in some cases. It’s easy to change in your VyOS config though. The point of the patch was presumably just to make VyOS work reliably, which I assume it didn’t when the kernel just generated a random MAC on each boot.
I wouldn’t call messing around in u-boot with a console cable particularly user friendly. 
How does OpenWrt handle this? Does it automatically save MAC addresses generated on first boot or are they hardcoded?
you can also set mac with init-system (e.g. systemd)
@Canoziia It seems you don’t have a linux/amd64 version of that docker image. What’s in it?
I thought you cross-compiled to aarch64? Are you compiling on an ARM machine or in QEMU?
EDIT: I’ll try it in my aarch64 Oracle VPS. Hopefully it has enough storage.
Looks like the docker image is debian with the build tools
My idea is to let users change their mac address using built-in vyos command (set interface ethx mac xx:xx:xx:xx:xx:xx). If an interface always change its mac after reboot, vyos will have difficulty finding the correct interface.
I remember when I was testing the images, all the 1G ports were unusable unless I changed the device tree labels. VyOS uses net.ifnames=0 on x86 to rename all interfaces to ethx, because it only supports configuring interfaces named ethx.
I modified their labels to eth3-eth6 because, without the change, the switch root and the two 10G ports would be assigned as eth0-2. However, after applying this device tree patch, these ports seem to be renamed to eth2-8.
mtk_soc_eth 15100000.ethernet eth0: mediatek frame engine at 0xffff800087100000, irq 102
mtk_soc_eth 15100000.ethernet eth1: mediatek frame engine at 0xffff800087100000, irq 102
mtk_soc_eth 15100000.ethernet eth2: mediatek frame engine at 0xffff800087100000, irq 102
mt7530-mmio 15020000.switch eth3 (uninitialized): PHY [mt7530-0:00] driver [Generic PHY] (irq=POLL)
mt7530-mmio 15020000.switch eth4 (uninitialized): PHY [mt7530-0:01] driver [Generic PHY] (irq=POLL)
mt7530-mmio 15020000.switch eth5 (uninitialized): PHY [mt7530-0:02] driver [Generic PHY] (irq=POLL)
mt7530-mmio 15020000.switch eth6 (uninitialized): PHY [mt7530-0:03] driver [Generic PHY] (irq=POLL)
mtk_soc_eth 15100000.ethernet eth0: entered promiscuous mode
mt7530-mmio 15020000.switch e7: renamed from eth3
mt7530-mmio 15020000.switch e9: renamed from eth5
mtk_soc_eth 15100000.ethernet e4: renamed from eth0
mt7530-mmio 15020000.switch e8: renamed from eth4
mtk_soc_eth 15100000.ethernet e6: renamed from eth2
mt7530-mmio 15020000.switch e10: renamed from eth6
mtk_soc_eth 15100000.ethernet e5: renamed from eth1
Yes,but this userspace and so you can set it via systemd easier…uaer do not want to change kernel/devicetree. Or does it work when using devicetree only as default and overriding this in userspace somehow?
Oh, I see. Interesting. I guess I’ll get to confirm that myself too, since I tried removing the renaming in my updated patch and instead just added the MAC addresses. Unfortunately, since I need to build it on my VPS I can’t test changes particularly fast.
I sent a pull request to fix the build btw. One of the patches is no longer necessary as it was fixed in upstream a few days after your last build.
This cmdline param does not rename any ports it tells userspace (e.g. systems-networkd) not to rename it to predictable interface names and stay on kernel naming.
You cannot compare with x86 as there you mostly have only MACs,no dsa and similar things. On R4 you can access 2 MACs from SoC directly (eth1+2) but not eth0 as it is the cpu port of switch ports (wan,lanX). Renaming all to ethX is imho misleading.
This is what the interfaces end up being named as without changing the label in the device tree from what’s in frank-w’s kernel:
vyos@vyos:~$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address MAC VRF MTU S/L Description
----------- ------------ ----------------- ------- ----- ----- -------------
eth2 - 62:0f:90:15:4f:8b default 1504 A/D
eth3 - 02:00:00:b3:14:42 default 1500 A/D
eth4 - 02:00:00:b3:14:41 default 1500 A/D
lan1 - 02:00:00:b3:14:44 default 1500 A/D
lan2 - 02:00:00:b3:14:45 default 1500 A/D
lan3 - 02:00:00:b3:14:46 default 1500 A/D
lo 127.0.0.1/8 00:00:00:00:00:00 default 65536 u/u
::1/128
Not sure what happened with the RJ45 wan interface. I set a MAC address ending in 43 for it in the device tree but that clearly isn’t used.
VyOS is unable to detect a link on any of the network interfaces. 
For the SFP+ slots I tried with both a 10G DAC as well as a 10GBASE-SR fiber transceiver. I also tried with 10GBASE-T transceivers, which did at least light up the link light on the switch at the other end, but still no link detected.
All of the transceivers and DACs work fine in OpenWrt.
Any ideas?
This is the patch I used instead of 0001-bpi-r4-eth-name.patch:
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dts b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dts
index 499f0c91c213..cf5b6bb6adbb 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dts
@@ -27,6 +27,7 @@ &gmac1 {
managed = "in-band-status";
phy-mode = "usxgmii";
sfp = <&sfp2>;
+ local-mac-address = [02 00 00 b3 14 42];
status = "okay";
};
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi
index 358ac1df35dd..581e1ae23a77 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi
@@ -166,6 +166,7 @@ &gmac2 {
managed = "in-band-status";
phy-mode = "usxgmii";
sfp = <&sfp1>;
+ local-mac-address = [02 00 00 b3 14 41];
status = "okay";
};
@@ -182,6 +183,7 @@ &gsw_phy0_led0 {
&gsw_port0 {
label = "wan";
+ local-mac-address = [02 00 00 b3 14 43];
};
&gsw_phy1 {
@@ -197,6 +199,7 @@ &gsw_phy1_led0 {
&gsw_port1 {
label = "lan1";
+ local-mac-address = [02 00 00 b3 14 44];
};
&gsw_phy2 {
@@ -212,6 +215,7 @@ &gsw_phy2_led0 {
&gsw_port2 {
label = "lan2";
+ local-mac-address = [02 00 00 b3 14 45];
};
&gsw_phy3 {
@@ -227,6 +231,7 @@ &gsw_phy3_led0 {
&gsw_port3 {
label = "lan3";
+ local-mac-address = [02 00 00 b3 14 46];
};
&i2c0 {
EDIT: It seems like the issue with VyOS not detecting a link happens when the interfaces are not added to the configuration. Manually adding them makes it establish a link. I realized this after I tried your latest build and running into the exact same issue with all ports except eth5. It works in my build too, except I don’t see the RJ45 wan interface (i.e. the leftmost RJ45 port from the front) for some reason in my build, just like I mentioned before. 
Normally, VyOS would enumerate and add all detected network interfaces to the configuration automatically, but I assume the config override used in your builds to allow people to access the device via SSH without first setting it up using a serial console cable.
The wan interface shows up in ip a:
7: wan@eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 02:00:00:b3:14:43 brd ff:ff:ff:ff:ff:ff
Trying to change it’s state to UP using ifconfig results in the following, so it seems like something fails in the initialization for that interface for some reason based on the LOWERLAYERDOWN state:
7: wan@eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000
link/ether 02:00:00:b3:14:43 brd ff:ff:ff:ff:ff:ff
I’m sure this is because of the renaming…wan is connected via eth0 normally…just drop the ethernet renaming as start.
Other than adding the MAC addresses as you can see above, I haven’t changed the naming from what’s in your existing dts + dtsi. Do you mean I should just remove the label lines you added too?
No,something renames eth0 to eth2.
I don’t know what though. The dts/dtsi doesn’t and I have no idea what else might be doing so. I didn’t see anything obvious in the dmesg log.
Any ideas where to look?
Renaming normally is printed in dmesg.