OrangePi 3b ethernet problem (again...)

[rlwneth]

I have lost track solving the ethernet (eth0) problem with my opi3bv2.1 board
I have read:

Ethernet not working in the new version of Orange Pi 3B

Orange Pi 3B has a new version, 2.1: Orange Pi 3B V2.1 SBC has been revamped with better WiFi 5 connectivity, M.2 2280 NVMe/SATA SSD socket - CNX Software (cnx-software.com) I got this new board this week. I know the new thing is the wifi chip, and wifi is working fine. For some reason, the problem is the ethernet, there’s no connectivity. Ethernet is working fine in the official Linux version of Opi 3B. What can I do to help to solve this issue?

From the thread I had the impression that with the later releases the proper dtb would be detected and linked accordingly.
However, I have an op3bv2.1, at least that’s what is printed on the board, but the dtb used is the one for v.1.1:

root@DietPi:~# ls -l /boot/dtb-6.18.7-current-rockchip64/rockchip
-rw-r–r-- 1 root root 116954 Jan 26 00:39 rk3566-orangepi-3b-v2.1.dtb
lrwxrwxrwx 1 root root 27 Jan 26 00:39 rk3566-orangepi-3b.dtb → rk3566-orangepi-3b-v1.1.dtb
-rw-r–r-- 1 root root 115373 Jan 26 00:39 rk3566-panther-x2.dtb

I initially started with the trixy image from oktober 25: DietPi_OrangePi3B-ARMv8-Trixie.img
After configuring the basics I transferred that image to the emmc memory (manually) end from there I recently started configuringing it as a home server.
Quite soon I found out that there were problems with eth0 at 1Gb.

So I ended up with the MAC workaround:

Ethernet not working in the new version of Orange Pi 3B

I have a dirty workaround for it. Edit the file: /etc/network/interfaces Add a line with a mac: hwaddress ether AA:BB:CC:DD:EE:FF In my case is something like: # Ethernet allow-hotplug eth0 iface eth0 inet dhcp address 192.168.8.100 netmask 255.255.255.0 gateway 192.168.8.1 hwaddress ether 02:03:46:C1:5F:E6 And that’s it.

Any ideas what I have missed?

• why is it still using v.1.1 dtb? Is the detection of the proper dtb not working?
• I suppose I can also add in: /boot/dietpiEnv.txt
  fdtfile=rockchip/rk3566-orangepi-3b-v2.1.dtb

But will that survive any update in the future?

Any suggestion welcome.

[MichaIng]

Why do you think it uses the v1.1 dtb? Check it this way:

cat /proc/device-tree/model

What issues do you face with the Ethernet? The MAC address should be static since a long time.

[rlwneth]

I assumed that the link reference as shown in the /boot/dtb-6.18.7-current-rockchip64/rockchip
directory points to the dtb that is actually used.
What I see there is the “generic” dtb name that links to the v1.1 dtb. Apparently my assumption is wrong because if I enter:
cat /proc/device-tree/model
Xunlong Orange Pi 3B v2.1

The problem I experienced with the board is that with the eth0 auto setting or the forced 1000Mbit setting configured with dietpi-config the ssh connection became unresponsive.
journalctl -b showed messages of link up /down events:

Blokcitaat
Jan 29 17:57:43 DietPi 94e7a50c87d0[489]: File “/app/dsmr_datalogger/scripts/dsmr_datalogger_api_client.py”, line 43, in read_telegram
Jan 29 17:57:43 DietPi 94e7a50c87d0[489]: raise RuntimeError(“Failed to connect: {}”, error) from error
Jan 29 17:57:43 DietPi 94e7a50c87d0[489]: RuntimeError: (‘Failed to connect: {}’, SerialException(‘Could not open port socket://192.168.178.37:82: timed out’))
Jan 29 17:57:43 DietPi 94e7a50c87d0[489]:
Jan 29 17:57:48 DietPi kernel: rk_gmac-dwmac fe010000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Jan 29 17:57:51 DietPi 94e7a50c87d0[489]: Starting DSMR Reader - datalogger…
Jan 29 17:57:51 DietPi 94e7a50c87d0[489]: 127.0.0.1 - - [29/Jan/2026:17:57:51 +0100] “GET /about HTTP/1.1” 200 13048 “-” “curl/8.14.1” “-”
Jan 29 17:57:52 DietPi kernel: rk_gmac-dwmac fe010000.ethernet eth0: Link is Down
Jan 29 17:57:54 DietPi kernel: rk_gmac-dwmac fe010000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Jan 29 17:57:56 DietPi kernel: rk_gmac-dwmac fe010000.ethernet eth0: Link is Down
Jan 29 17:57:59 DietPi kernel: rk_gmac-dwmac fe010000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Jan 29 17:58:00 DietPi kernel: rk_gmac-dwmac fe010000.ethernet eth0: Link is Down
Jan 29 17:58:02 DietPi kernel: rk_gmac-dwmac fe010000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Jan 29 17:58:02 DietPi 94e7a50c87d0[489]: 127.0.0.1 - - [29/Jan/2026:17:58:02 +0100] “GET /about HTTP/1.1” 200 13048 “-” “curl/8.14.1” “-”
Jan 29 17:58:03 DietPi kernel: rk_gmac-dwmac fe010000.ethernet eth0: Link is Down
Jan 29 17:58:04 DietPi 94e7a50c87d0[489]: Current logging level set to “ERROR”. More information can be found here: Troubleshooting: Enable DEBUG logging — DSMR-reader v5 documentation
Jan 29 17:58:06 DietPi 94e7a50c87d0[489]: Traceback (most recent call last):
Jan 29 17:58:06 DietPi 94e7a50c87d0[489]: File “/usr/local/lib/python3.12/site-packages/django/db/backends/base/base.py”, line 219, in ensure_connection
J

The messages before and after the link up/down events are messages from a docker container not able toe connect anymore.

I searched for information about this ethernet problem and found the issue discribed here:
https://www.reddit.com/r/OrangePI/comments/1aojmn3/comment/nz1wa0n/?utm_name=mweb3xcss

The problem was already 2 years old, but only a recent response explained how it could be implemented using a vendor specific linux “IO” executable.

I downloaded the manufacturers debian image extracted this IO executable and tried it , but that did not solve the problem. After the suggested IO commands the system froze so it was no solution to my problem.

Then I found the same(?) problem discussed at the dietpi forum. Setting the interface to 100Mb also solved the problem, but I need the 1Gb speed for file transfers. Going through the thread I tried adding a MAC address in /etc/network/interfaces and from then on the 1Gb link remained stable.

Blokcitaat
root@DietPi:~# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
master-slave cfg: preferred slave
master-slave status: slave
Port: Twisted Pair
PHYAD: 1
Transceiver: external
MDI-X: Unknown
Supports Wake-on: ug
Wake-on: d
Current message level: 0x0000003f (63)
drv probe link timer ifdown ifup
Link detected: yes

At the moment the uptime is a few days, I checked again for up/down link reports with journalctl , but found none. But I don’t like the idea that “some” workaround solves this problem and that I do not understand why.
I see the restriction of not being able to use dietpi-config any more as minor, because a cannot think of future changes to come. However I also don’t like the idea of experiencing a problem that seems to have been solved more then a year ago, but not in my system.

[rlwneth]

I may have found the source of the problem…
When trying to find an explanation for the eth0 instability I also disconnected the patch cable once or twice.
Together with the static MAC address its seemed that the latter solved the instability, but I think I was wrong.
I deliberately used dietpii-config to have it arease the MAC entry in /etc/network/interfaces and watched what would happen: nothing! The link stayed stable. So I suppose I created the problem myself, assuming that the link to the v1.1. dtb indicated a wrong dtb. Due to a bad physical ethernet connection at the same time I started looking for a solution in the wrong direction.
Lessons learned? Never change more then one probable cause at the same time…
2nd lesson learned: what I see in the /boot/chipfamily_type/xyz.dtb list is just a list of all dtbs’s for the family members available. On my nanopi board I see the same linkk voor the op3b pointing to the v1.1. dtb. So my initial assumption about which dtb is used by the kernel was incorrect.
Apologies for the inconvenience…