[Bug]: Ethernet rarely connecting successfully in Orange Pi 3 LTS

[iMagz]

What happened?

 

Orange Pi 3 LTS rarely recognize ethernet connection.

 

How to reproduce?

 

Flash Orange Pi 3 LTS with an image of the latest version of Armbian.

 

Extra Info

 

The latest images tested which worked flawlessly was: 

 

Armbian_community_25.11.0-trunk.437_Orangepi3-lts_trixie_current_6.12.47_minimal.img

 

Armbian_23.8.3_Orangepi3-lts_jammy_current_6.1.53_minimal.img

 

 

Images tested which didn't worked:

 

Armbian_community_26.2.0-trunk.151_Orangepi3-lts_trixie_current_6.12.63_minimal.img

 

Armbian_community_26.2.0-trunk.100_Orangepi3-lts_trixie_current_6.12.63_minimal.img

[Werner]

logs?

[Werner]

May have found something. Perhaps https://lists.openwall.net/linux-kernel/2025/09/17/618 causes issues.

Here is a test image that works around this by adjusting device tree a bit. Please test and report

 

https://testing.armbian.de/Armbian-unofficial_26.02.0-trunk_Orangepi3-lts_trixie_current_6.12.63_minimal.img.xz

 

[iMagz]

Here I leave my logs, if you need additional ones let me know:

 

ip a

 

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: end0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether [MAC ADDRESS] brd ff:ff:ff:ff:ff:ff
    altname enx[XXXXX]
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether [MAC ADDRESS] brd ff:ff:ff:ff:ff:ff
    altname wlx[XXXXX]

 

I tested the image provided and after numerous reboots it didn't work, still the same problem.

Doing some other testing i compile the following image Armbian-unofficial_26.02.0-trunk_Orangepi3-lts_forky_edge_6.18.2_minimal.img which I extracted it from Armbian GitHub from this tag: "v26.2.0-trunk.146" https://github.com/armbian/build/releases/tag/v26.2.0-trunk.146 and it worked. i don't know if it has to the with the kernel version or something but I think is something to consider.

Edited 52 minutes ago by iMagz
To format it better.

[Werner]

6 hours ago, iMagz said:

Doing some other testing i compile the following image Armbian-unofficial_26.02.0-trunk_Orangepi3-lts_forky_edge_6.18.2_minimal.img which I extracted it from Armbian GitHub from this tag: "v26.2.0-trunk.146" https://github.com/armbian/build/releases/tag/v26.2.0-trunk.146 and it worked. i don't know if it has to the with the kernel version or something but I think is something to consider.

So to cut a long story short 6.18.y kernel image works? If so then this issue has low priority since 6.18 will replace 6.12 as current in a few month anyway since it is the new LTS kernel upstream.

[Werner]

Different attempt. Instead of working around trying to revert which might be the root cause: https://lists.openwall.net/linux-kernel/2025/09/17/618

 

I'll provide you with another image containing this adjustment shortly. https://testing.armbian.de/Armbian-unofficial_26.02.0-trunk_Orangepi3-lts_trixie_current_6.12.63_minimal.img.xz

 

 

Could you do me a favour and execute these commands on both in a non-working state of a broken image and in working state of a good image?

 

dmesg | grep -i "phy.*halt\|mdio.*reset"
watch -n 1 'ethtool eth0 | grep -E "Speed|Duplex|Link detected"'
cat /sys/class/net/eth0/phydev/phy_state 2>/dev/null

 

Edit: https://testing.armbian.de/Armbian-unofficial_26.02.0-trunk_Orangepi3-lts_trixie_current_6.12.63_minimal_regulator_fix.img.xz  this image follows another different approach by adjusting regulators which may cause issues. Feel free to test

[iMagz]

Unfortunately I tested both of the images provided and neither worked. After testing the images I ran the commands that were asked to be run on the following images:
 

Armbian-unofficial_26.02.0-trunk_Orangepi3-lts_trixie_edge_6.18.2_minimal.img [ETHERNET CONNECTION WORKING]

(I realized that forky isn't for me so I compile it with trixie which is used for the official images and it also works)

 

Armbian_community_26.2.0-trunk.151_Orangepi3-lts_trixie_current_6.12.63_minimal.img [ETHERNET CONNECTION NOT WORKING]
 

dmesg | grep -i "phy.*halt\|mdio.*reset"

 

In both images it didn't show any output.

 

 

 

watch -n 1 'ethtool eth0 | grep -E "Speed|Duplex|Link detected"'

 

Every 1.0s: ethtool eth0 | grep -E "Speed|Duplex|Link detected"                          orangepi3-lts: Mon Dec 29 21:48:01 2025

netlink error: no device matches name (offset 24)
netlink error: No such device
netlink error: no device matches name (offset 24)
netlink error: No such device
netlink error: no device matches name (offset 24)
netlink error: No such device
netlink error: no device matches name (offset 24)
netlink error: No such device
netlink error: no device matches name (offset 24)
netlink error: No such device
netlink error: no device matches name (offset 24)
netlink error: No such device
netlink error: no device matches name (offset 24)
netlink error: No such device

 

In both images it showed this because Armbian use end0 instead of eth0 so I ran it with end0 instead and it showed this:

 

[Ethernet Connection NOT working image]

 

Every 1.0s: ethtool end0 | grep -E "Speed|Duplex|Link detected"                          orangepi3-lts: [DATE]

	Speed: Unknown!
	Duplex: Unknown! (255)
	Link detected: no

 

[Ethernet Connection working image]

 

Every 1.0s: ethtool end0 | grep -E "Speed|Duplex|Link detected"                          orangepi3-lts: [DATE]

	Speed: 1000Mb/s
	Duplex: Full
	Link detected: yes

 

 

 

cat /sys/class/net/eth0/phydev/phy_state 2>/dev/null

 

In both images it didn't show any output. I think is because not only is end0 instead of eth0, which I tested by changing them, but also there isn't any phy_state file in the /sys/class/net/eth0/phydev/ directory.