14 minutes ago, Igor said:

 

 

Put few thousands on our account if you have such ideas or hire someone to get you that information. We have shared all we know - we always do that. To get a better information, to find a bug, additional time has to be lost. Perhaps a day is enough, perhaps a week wont. And we have other, much more important things to do. We would improve this service, but you don't care so ... 

 

@Igor - I have just put a few thousands on your account. Can I therefore kindly a request a withdrawal of the "you don't care" part of the above? Thank you.

20 minutes ago, Adrian Cable said:

Thank you.

Likewise! 

2 minutes ago, Igor said:

Likewise! 

 

You are (very genuinely) welcome!

For those who end up here via search engines:

 

On a NanoPI M4V2 (RK3399) I activated the `tuned` profile "latency-performance" for my use case without the intention to address this issue. Thus, by coincidence, I recognized that the issue apparently disappeared (or got a lot less frequent, at least, since it hasn't appeared in the last 12 hours). I don't have the time/priority to track down which of the settings actually helped but it should be the governor or cstate settings.

Thank you @lpirlfor your tip, unfortunately it did not work on my Orange Pi PC (H3 CPU), running Armbian 22.05.1 Bullseye with Linux 5.15.43-sunxi.

Here is what I tried (as root) :

apt install tuned tuned-utils tuned-utils-systemtap
tuned-adm profile latency-performance
reboot

 

It happens since I changed my ISP (and the router they provide). I tried all ethernet ports, but unfortunately nothing worked

@guidolwas right, I will try to put a switch between the router and the OPi to see if it gets better!

Hi All.

 

I have nanopi-neo with exactly the same problem.

What I've found is that link may be established if i turn off autonegotiation on my PC and force 10Half mode.

However it is still not fully functional. I can seed Rx packets are growing as well as Tx packets. But there are no packets actually transmitted (checked with wireshark on PC).

 

I can experiment. Can anyone suggest what should I try to troubleshoot?

On an orange pi one I notice the same regularly:

 

│Jan 21 15:50:25 a-m kernel: [ 1757.658898] dwmac-sun8i 1c30000.ethernet eth0: Link is Down                                                                                                         │
│Jan 21 15:50:27 a-m NetworkManager[1119]: <info>  [1674312627.1444] device (eth0): carrier: link connected
  ...

 

I can test with multiple samples.

Hi there.

I have a Pine A64(+) board (https://pine64.org/documentation/Pine_A64/)

I have been experiencing this issue since last year. I updated the SO (armbian version + kernel) several times and it didn't resolve the issue.
It happens randomly. The CPU and storage are not overheated (30º C each) and I tested all physical components (board, ethernet wire, switch, ...)

ambianmonitor -u -> https://paste.armbian.com/arozepuxen

 

Things I tested for now:
- Daily reboot. Sometimes eth0 is not wake up after boot and I have to physically power-toggle the board.

- Stay on latest raspbian release (24.2.1) + latest kernel (6.6.16) + latest uboot. Same issue.

- Stay on latest raspbian release (24.2.1) + legacy kernel (6.1.77) + latest uboot. Same issue.

- Armbian 23.11.1 Jammy with Linux 6.1.63-current-sunxi64 was also some time the SO in the board. Same issue.

- Also I set the segmentation and MTU as here but same issue:

 

Notes:

- CPU is "on demand". That's also why the temperature is OK.

- Somehow is only 100Mbits available (the board has gigabit port). By the way, is not my concerning now.

- https://github.com/jwrdegoede/rtl8189ES_linux/tree/rtl8189fs I saw this driver. Is this an option? Should I try?

Any idea? Should I totally rebuild the microsd SO from zero with an ARMBIAN from 2021 or so?
Any other suggestion? The board is totally unstable as it currently is and I guess is software related (driver maybe)

Thank you.
 

Update:

I "fixed it" with https://mmonit.com/wiki/Monit/Installationmonit

 

Basically, each 60 seconds it will check if my "eth0" ethernet interface is up. If not, it tries to wake it up.

If for some reason, the port/board cannot wake up the ethernet interface... I have a secondary check (ping Google DNS IP 10 times in a row -> one per minute). If 10/10 failed, it reboots the board.

 

Is not ideal, but now I have a "hands free" board. This is in a countryside, so before this "patch", I had to take my car to manually power-cycle the board hahaha

Here you have, the config I used:

 

Quote

/etc/monit/monitrc

## Start Monit in the background (run as a daemon):
#
set daemon  60             # check services at 60 seconds intervals
   with start delay 120    # optional: delay the first check by 2-minutes (by
#                           # default Monit check immediately after Monit start)
#
set log /var/log/monit.log
set idfile /var/lib/monit/id
set statefile /var/lib/monit/state
 set eventqueue
     basedir /var/lib/monit/events  # set the base directory where events will be stored
     slots 100                      # optionally limit the queue size

###############################################################################
## Services
###############################################################################
##
check network eth0 with interface eth0
  start program = "/sbin/ifconfig eth0 up"
  stop program = "/sbin/ifconfig eth0 down"
  if link down then restart

check host 8.8.8.8 with address 8.8.8.8
  if failed ping count 10 size 128 with timeout 10 seconds then exec "/usr/sbin/reboot"

 

 

 I hope this can be helpful to somebody.

 

Regards

Edited June 3, 20242 yr by Dav

Hi! I had the same problem on OrangePI PC Plus. 

I have tried different images, settings, and power supply but nothing helps.

 

Then I checked my router Netis(N1) and  I found my OrangePI in DHCP clients with another IP. Not static IP that I set manually. Maybe It was IP conflict between the static IP I set on the device and the DHCP IP router had in memory.

I reserved IP on the router directly for the specific OrangePI Mac address. After this ethernet works stable for the 16 hours.

Here is my findings and solution. Hope this also solves your problem.

 

When the network hangs, I can see that IPv4 address is lost using "ip a" on the console. I then check "journalctl -b -e" for logging and obviously it's a consequence of dhcp4 failure.

 

Dec 19 22:54:10 pbsbc01h3 dhclient[4720]: DHCPREQUEST for 192.168.2.190 on eth0 to 192.168.2.55 port 67 (xid=0xb07e1eb)
Dec 19 22:54:10 pbsbc01h3 dhclient[4720]: DHCPACK of 192.168.2.190 from 192.168.2.55 (xid=0xebe1070b)
Dec 19 22:54:10 pbsbc01h3 NetworkManager[5189]: <error> [1766156050.2239] dhcp4 (eth0): error -111 dispatching events
Dec 19 22:54:10 pbsbc01h3 NetworkManager[5189]: <info>  [1766156050.2243] dhcp4 (eth0): state changed bound -> fail
Dec 19 22:54:10 pbsbc01h3 NetworkManager[5189]: <info>  [1766156050.2248] device (eth0): DHCPv4: trying to acquire a new lease within 90 seconds
Dec 19 22:54:10 pbsbc01h3 dhclient[4720]: bound to 192.168.2.190 -- renewal in 288 seconds.

 

With the help from ChatGPT, I modify "/etc/dhcp/dhclient.conf" with the following and the problem is gone.

 

timeout 5;
retry 60;
reboot 10;

 

This is based on mines, running  Armbian Trixie:

 

- NM can work without dhclient, it has it DHCP internally as well. So maybe look at that instead of AI with old info and certainly no clue about a specific SBC

- modern kernel it is end0

- systemd-networkd is also an option

- you also might use ifupdown still, also not needed, NM can do internally as well

 

 

Edited December 19, 2025Dec 19 by eselarm