Network problem on reboot - Orange pi zero 3


I installed this DietPi script on Orange Pi Zero 3 :slight_smile:

bash -c "$(curl -sSfL '')"

Everything works fine except wifi not working, but that’s ok. The funny thing is etho only works if I hard reboot the pi. If it reboot from console with ‘reboot’, eth0 not works.

Here the logs from the boot afte a reboot command:

ifup@eth0.service: Bound to unit sys-subsystem-net-devices-eth0.device, but unit isn't active.
Dependency failed for ifup@eth0.service - ifup for eth0.
ifup@eth0.service: Job ifup@eth0.service/start failed with result 'dependency'.

Any tips?

Anyone? Please?

I had an Orange Pi Zero Plus2 and had similar issues that WiFi did not work. I tested quite much with Armbian and the DietPi conversion script.
The problem was that the Armbian image did not support the WiFi.
It ended up with sellih my Opi 0+2 and use a different hardware type. sniff

Well my problem is not wifi, is Ethernet that only works on hardware reboot. If I software reboot there’s no Ethernet.

Maybe if I put a cron job script to bring up ethert on boot? Just thinking…

But um using dietpi normally besides that.

@MichaIng any ideas?

Well I just installed a hardware button that I can control by Alexa, that way I can power on and off without login the network. Not the best workaround, I gonna wait if this board can be supported officially. (I also have a Orange Pi 3b, in this one I can’t even start the network)

just like to point to an ‘in development’ thread on github

test images are now created for Orange Pi Zero 3 (review the thread)

the test images are here, but do review the above thread prior to using test images, at least to understand the issues etc

I’ve done an install, and complete logs of the issues encountered during install and initial run
see the same github thread at end

There are apparently some hardware issues with the YT8531 gigabit ethernet chip as documented in my install and initial run log.

tagging: @MichaIng and developers
As for Wifi, apparently the UWE5622 (also known as: CdTech 20U5622) drivers are not in mainline kernel codes and apparently needs to be patched into the kernel sources for the build
I’ve placed a comment in the github thread but that I can only place 2 links in this comment for now.
apparently, (note I’m not sure about this) :
the more stable releases for the codes may be found from OrangePi in their linux-orangepi repository
under the orange-pi-6.1-sun50iw9 branch or better
orange-pi-6.6-rk35xx branch for 6.6 kernel

There are apparently various updates in the mainline kernel at the 6.6+ versions as related to Orange Pi Zero 3 (the dts template is furnished) as well as for Orange Pi Zero 2W (dts template)
however, that the UWE5622 source codes are not in mainline and the specs are practically undocumented for this WiFi chip.

In my tests the ethernet link dropped on reboot, and it drops after being idle for about 45 minutes (possibly earlier) are apparently a hardware issue related to YT8531 gigabit ethernet chip. strangely sometimes, it seemed I magaged to reboot without losing ethernet. Hence, this is hit and miss.

In my current tests, the hardware issues apparently is with the ethernet chip, UWE5622 Wifi seemed to work ok provided that the ‘correct’ source codes for the drivers are built with it.

These are my own observations, however, those who have the board are encouraged to run installs and tests with the test images so as to reproduce errors and probe issues etc. and to feedback on the same. Note however, it is unknown if the ethernet hardware issues mentioned prior if indeed thay are hardware defects can be fixed in codes.

probably due to my unfamiliarity with DietPi, it turns out UWE5622 is built into the kernel in the test image. But that instead of UWE5622 it is detected as sprdwl_ng for the wifi module. I’ve (accidentally) triggered by installing some wireless packages, e.g. in my case wireless hotspot. It results in this module being probed and installed.

tag: @MichaIng , developers and other OPi Zero 3 board users:

uwe5622 wifi module is actually sprdwl_ng

[  OK  ] DietPi-Software | Initialised database
[  OK  ] DietPi-Software | Reading database
[ SUB1 ] DietPi-Set_hardware > wifimodules (enable)
[  OK  ] DietPi-Set_hardware | eval echo 'sprdwl_ng' > /etc/modules-load.d/dietpi-enable_wifi.conf
[  OK  ] DietPi-Set_hardware | rm /etc/modprobe.d/dietpi-disable_wifi.conf
[ INFO ] DietPi-Set_hardware | Please wait, enabling WiFi modules...
[  OK  ] DietPi-Set_hardware | modprobe cfg80211
[  OK  ] DietPi-Set_hardware | modprobe sprdwl_ng
[ INFO ] DietPi-Set_hardware | Checking for required APT packages: iw wireless-tools wpasupplicant wireless-regdb
[  OK  ] wifimodules enable | Completed
dietpi@DietPi:~$ sudo iw dev
     Interface wlan0
             ifindex 3
             wdev 0x1
             addr 80:a0:53:73:a3:89
             type managed
dietpi@DietPi:~$ ip link 
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 mq state UP mode DEFAULT group default qlen 1000
    link/ether 02:00:6c:53:f7:f9 brd ff:ff:ff:ff:ff:ff
    altname end0
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 80:a0:53:73:a3:89 brd ff:ff:ff:ff:ff:ff
dietpi@DietPi:~$ sudo iw list 
Wiphy phy0
     wiphy index: 0
     max # scan SSIDs: 12
     max scan IEs length: 2304 bytes
     max # sched scan SSIDs: 9
     max # match sets: 9
     RTS threshold: 2353
     Retry short limit: 10
     Retry long limit: 9
     Coverage class: 0 (up to 0m)
     Device supports RSN-IBSS.
     Supported Ciphers:
             * WEP40 (00-0f-ac:1)
             * WEP104 (00-0f-ac:5)
             * TKIP (00-0f-ac:2)
             * CCMP-128 (00-0f-ac:4)
             * WPI-SMS4 (00-14-72:1)
             * CMAC (00-0f-ac:6)
             * 00-0f-ac:255
     Available Antennas: TX 0x1 RX 0x1
     Supported interface modes:
              * IBSS
              * managed
              * AP
              * P2P-client
              * P2P-GO
              * P2P-device
     Band 1:
             Capabilities: 0x16f
                     RX LDPC
                     SM Power Save disabled
                     RX HT20 SGI
                     RX HT40 SGI
                     RX STBC 1-stream
                     Max AMSDU length: 3839 bytes
                     No DSSS/CCK HT40
             Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
             Minimum RX AMPDU time spacing: 2 usec (0x04)
             HT RX MCS rate indexes supported: 0-7
             HT TX MCS rate indexes are undefined
             Bitrates (non-HT):
                     * 1.0 Mbps
                     * 2.0 Mbps
                     * 5.5 Mbps
                     * 11.0 Mbps
                     * 6.0 Mbps
                     * 9.0 Mbps
                     * 12.0 Mbps

what remain is still the (gigabit) ethernet chip (PHY) YT8531 that drops connection on reboot or idle for an hour (probably less)

can others having the board try to reproduce what I observed?
this is because there have been reports of stable ethernet connections, it would be good to feedback / share about its details here e.g. dmesg etc.

I did it once again

  • setup bridge
    install bridge-utils apt-get install bridge-utils
#allow-hotblug br0
auto br0
iface br0 inet static
    #bridge_ports eth0 wlan0, wlan0 would be placed on the bridge by hostapd
    bridge_ports eth0
    up /usr/sbin/brctl stp br0 on
  • reboot
  • install hostapd
apt install hostapd

and with this hostapd.conf


systemctl start hostapd

I managed Wifi 802.11ac 5ghz, the throughput on OrangePi Zero 3 on both the gigabit ethernet and UWE5622 Wifi exceeds 100 Mbps (100 mega bits per seconds) on the wifi hotspot. And this is running in DietPi with the test image from 24 Nov 2023 .

Unfortunately, the ethernet hardware remains unstable and it defeats running this as a hotspot

on the record, it is up 2 hours with the AP on hostapd in the current test, so ethernet disconnect/hang is pretty much hit and miss. There are records it hangs in less than 45 minutes, then now it works for longer. it is very much hit and miss.

 19:56:24 up  2:30,  2 users,  load average: 1.01, 1.02, 1.00

did some android app updates on a phone over wifi, transferred about 1 GB over the ethernet chip and wifi, link still up.

disconnected, this is caused by moving the board around a little. fixed by adjusting the ethernet cable a little, led comes back on. So a loose cable is part of the cause, but that this isn’t the only case

tests, observed 2 cases of ethernet disconnect:

  • loose cable, fixed by adjusting cable

  • ethernet lost connection after some time, possibly due to heating or some other hardware issues. requires a full power cycle to recover and did not recover initially, only after a minute that it is successful.
    it is uncertain if it has anything to do with the hub/switch which it is connected to.

  • ethernet link disconnects recovers on its own if ethernet set to run at 100Mbps
    ethtool -s eth0 speed 100
    unfortunately, ethernet still drop after several hours requiring cable adjustment
    e.g. disconnect / reconnect

better to discuss this on GitHub directly

after rather extensive tests on the etnernet interface

I ‘give up’, I ordered low cost usb-ethernet 10/100 mbps dongle to go with it.
There is ‘no point’ ordering 1 Gbps usb-ethernet to go with this, the built-in usb host ports is 2.0.
But using external usb dongles will increase power consumption, just hope that it works and is stable.

Had the onboard ethernet phyt worked well, this would have been a good board.

Hope the orange pi manufacturers would fix the ethernet hardware defects if after all this isn’t an isolated case.

We currently use the very same kernel, bootloader and firmware Orange Pi itself uses for their images. The Linux 6.6 branch is for Rockchip RK35xx (RK3588) SoC SBCs, like Orange Pi 5, while the Zero 3 uses an Allwinner H618, which is the Linux 6.1 branch for.

The WiFi adapter works here as well, though not awesome: Every input on SSH takes a second before it is reacted to, even that my router is very close. Others seem to have more issues with it. It is a 3rd party driver with 3rd party firmware which is often not a high quality development.

The issue with the Ethernet adapter is the same with official Orange Pi images, when using the same network tools. I am trying to get more info about this from Orange Pi gurus and from the Debian bug tracker, but so far no one reacted.

I aim to do an own kernel build based on Orange Pi’s sources, but since the last commit was in September, I don’t think it will behave any different. Next would be to test mainline Linux, but onboard WiFi will then surely not work.

hi @MichaIng

No worries about my reported issues, in particular about the ethernet issues. I’ve encountered them pretty seriously, but that if you review my tests, it essentially confirms a hardware problem with possibly the ethernet PHY YT8531 chip. However, as I’m testing it from a limited environment i.e. my desktop and I’m testing with a single piece, it isn’t known for sure if others observe the same unless they feedback on the same.

And that hardware issues are hardware issues, and unrelated to DietPi images. In fact, I’m liking DietPi for being ‘raw’, no NetworkManager or things ‘in between’ and it makes the hardware issues upfront when they surfaced, nearly bare metal. unlike in the vendor’s images, etc I’ve originally wondered why did Network Manager disable an interface, as I’ve had to enable that manually if network manager is used. In the case of DietPi, it is simply ip link, ethtool, ifup etc, right down bare. and dmesg and nothing between.

In addition, there is a way to overcome the current ethernet PHY issues, I’m resorting to buying a usb-ethernet adapter and using that. Hope it’d overcome the ethernet PHY hardware defect in my case.

I’d hope other users test other use cases for Diet Pi, e.g. other apps,. it seemed there is one related to hardware rng (e.g. rngd ?) that may need to be looked into e.g. that there is after all no hardware rng, but I’m not sure about it.

If that they are reasonably free of issues, my guess is ‘Test’ can reasonably be promoted to ‘supported’ .
Among the things ,I think video may not work. But that my use case is strictly server or simply the network and Wifi interfaces. Hence, others has to test that if it matters to them. At least to document what ‘doesn’t work’ - it is a feature, not a bug. It’d be good to maintain a ‘release notes’ documenting the source of the kernel e.g. from vendor images for version 6.1 kernel, the failures discovered e.g. a possibly bad ethernet PHY, UWE5622 wifi issues etc. these would be ‘known features’ as related to the present state-of-the-art :wink:

As new kernels etc become available e.g. the 6.6 versions and some works on uboot, I’ve not tested them myself, hopefully at some point those could be ‘mainlined’ i.e. from stock kernel and uboot.

Today the UWE5622 drivers are not in mainline as well, and hopefully that gets into the mainline kernel as well.

Apparently Orange Pi use UWE5622 Wifi as well as the PHY YT8531 on several of their boards. And so do some other board manufacturers notably Bigtreetech CB1 for the UWE5622

Those progress at the ‘bleeding edge’ could hopefully help to make the path ‘forward’ for more ‘streamlined’ supports for these boards (in (near) future).

an intresting sidenote, I randomly checked around for boards having Wifi and Ethernet, decent cpu and generous amount of ram. Because I had so much issues with the (possibly) bad ethernet PHY (note that when it works well I’ve witnessed >100 Mbps (mega bits per seconds) throughput on the wifi hotspot across UWE5622 Wifi and ethernet on Orange Pi Zero 3, that is good performannce), but that it is simply unstable.

And as I searched around for boards to replace Orange Pi Zero 3 as a Wifi AP hotspot, it turns out the competitors are either the Raspberry Pis - for stability and this Orange Pi Zero 3 being the lowest cost among the rivals say running Allwinner chips etc,. And many of Orange Pi’s rivals simply don’t have a good combination of having both Wifi (with antenna) (and can run as an AP) and high speed ethernet. but just bad that Orange Pi Zero 3 isn’t as stable and robust as like the Raspberry Pi’s, in both codes and hardware.

Guys, I have no problem with ethernet when using the official orange pi image. I’m right now running ubuntu for 90 days without a single problem, no disconnection and after I reboot, ethernet is up. But it only works with official Opi zero 3 image.

I had ethernet issues from the beginning with official image since the beginning few months back, and now with Diet Pi, so it looks like the ethernet hardware issue is specific to my board or setup. I could after all have a board with a defective ethernet PHY, possibly due to shorts on the PCB etc.

I’d just like to confirm that my hardware problem is likely specific to my piece of hardware.
I just downloaded and installed the recent Ubuntu Jammy image from Orange Pi’s official repository, released Oct 8, 2023
at the 1st boot

[  227.203860] dwmac-sun8i 5020000.ethernet eth0: Link is Down
[  235.395980] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[  236.419868] dwmac-sun8i 5020000.ethernet eth0: Link is Down
[  238.468106] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[  279.428894] dwmac-sun8i 5020000.ethernet eth0: Link is Down
[  544.646571] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[  675.719601] dwmac-sun8i 5020000.ethernet eth0: Link is Down

wiithin 4 minutes, dmesg is already showing link down events.
by 11 minute, the link down event, ethernet is disabled, led goes off.
disconnecting / reconnecting the cable didn’t make a difference.
And the link actually did not recover after a complete power cycle (disconnect / reconnect the usb C power cable)

But that this is the Orange Pi latest official image. This means that it isn’t a ‘DietPi’ defect.
i.e. it is a hardware problem (possibly with my single board and hardware setup, e.g. the upstream hub)

In short, Diet Pi is at least as good as what Orange Pi’s official images is. i.e. I’ve witnessed more than 100 Mbps (100 mega bits per seconds) setting up Diet Pi as a Wifi hotspot (AP) with the Orange Pi Zero 3 test image.
Just that the (my) ethernet hardware is not stable, and that this has nothing to do with Diet Pi, and possibly not a ‘software’ defect with their official images.

If others can get this to run stably, it is a good board considering the decent performance, generous ram (1GB, 2GB, 4GB versions) and low cost.

This isn’t ‘slow’ it is probably as good as Raspberry Pi 3B, which is a Cortex A53 board.

Others who have the board should also test other features, e.g. video, which I did not test myself.
All my runs are on the uart serial console, which is kind of ‘synthetic’, for the rest, do check if you can work with it connecting video and perhaps a keyboard, with Diet Pi’s test images for Orange Pi Zero 3

For the record i think @MichaIng rebuild the kernel for the Orange Pi Zero 3 image from sources.
I can’t get the Orange Pi’s official images to do 5ghz AP hotspot, but that the Diet Pi images did just that 5ghz 801.11ac and pushing out > 100 Mbps across the 2 interfaces. I only managed 2.4 Ghz 40 mbps with Orange Pi’s official images.
The hostapd.conf is here:


I did one thing, changed the ethernet cable. Maybe I should have done that earlier :rofl:

now it looks different:
I’ve just completed an Android apps update, Orange Pi Zero 3 is my Wifi hotspot, Orange Pi’s official ubuntu images released in Oct 23:

orangepi@orangepizero3:~$ vnstat
                      rx      /      tx      /     total
         today    413.90 MiB  /    5.22 MiB  /  419.12 MiB
         today      4.24 MiB  /  417.69 MiB  /  421.93 MiB

But that I only managed to configure a 2.4Ghz 802.11g wifi hotspot in the official images with hostapd. that is 40 Mbps. Throughput is decent though today. i’m running at 100 Mbps at the ethernet end.

1 link drop, recovers on its own - it’s a new cable ! uptime 1 hour

after replacing the cable with a new cable, link has been up 20 hours without a new link down event.
the hardware issue is a defective cable.

i just tried the same in diet pi at 100 Mbps ethernet, there is no apparent link drops this time after 30 minutes up time.

Please read my comments above and the GitHub issue linked: The issue does not happen when NetworkManager is used (like with the official Orange Pi images), but when using ifup on those, the same problem happens. So ifup seems to do something, which NetworkManager does not, which brings the adapter into a state where a soft reboot fails to reset it properly.

We are not gonna switch to a high level network stack for a single SBC only, so until this is either fixed kernel-wise, or we are able to find a workaround when using ifup, we have to live with this issue. I asked at Orange Pi GitHub repos (and about details regarding ifup at the Debian bug tracker), so sadly for now we are unable to proceed, aside of testing an own kernel build (from the same sources), to rule that out.

Ah, and of course NetworkManager can be installed and configured manually.


I managed to boot into DietPi with the test image, dmesg as related to ethernet as follows:

dietpi@DietPi:/sys$ dmesg |grep mac
[    3.770454] dwmac-sun8i 5020000.ethernet: IRQ eth_wake_irq not found
[    3.776867] dwmac-sun8i 5020000.ethernet: IRQ eth_lpi not found
[    3.782897] dwmac-sun8i 5020000.ethernet: No regulator found
[    3.788704] dwmac-sun8i 5020000.ethernet: PTP uses main clock
[    3.794583] dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 58000 (expect 0)
[    3.803983] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
[    3.811308] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
[    3.818611] dwmac-sun8i 5020000.ethernet: COE Type 2
[    3.823606] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
[    3.830405] dwmac-sun8i 5020000.ethernet: Normal descriptors
[    3.836065] dwmac-sun8i 5020000.ethernet: Chain mode enabled
[    9.200172] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[    9.202610] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [YT8531 Gigabit Ethernet] (irq=POLL)
[    9.202976] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
[    9.202988] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
[    9.202998] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
[    9.203346] dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii link mode
[   20.453910] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx

the link is setup up successfully with no apparent issues at 100 Mbps this time (after the cable change)
it is up 2 hours without a link down event so far

Strangely, I’ve forgotten where I set up the link to 100 Mbps, but that it started up at 100 Mbps instead of 1 Gbps as is default.

it is up 8 hours in DietPi without ethernet freezing out and completely dropping ethernet, it kind of confirms that my case is simply a cable defect. But that I’d leave it for the night and check again tomorrow. It is still on 100 Mbps though, but for now I’d leave it than try to figure out about it not connecting as 1 Gbps, before I changed the cable i’ve successfully done 1 Gbps.

Just’d like to say that i’m quite happy with the performance even currently, I’ve managed a 5ghz 802.11ac AP on the uwe5622 wifi and 100 mbps across the ethernet. speed tests shows that the combined throughput is more than 80 mbps as a WiFI hotspot. And it is with the DietPi test images.
it looks pretty good literally.

update, after an ethernet cable change (new cable), the (Orange Pi Zero 3) board is up exeeding 20 hours on Diet Pi test image as a Wi-Fi hotspot. I managed 5ghz 802.11ac on the uwe5622 Wi-Fi and 100 Mbps on the YT8531 Ethernet phy.

dietpi@DietPi:~$ uptime
 11:05:10 up 20:47,  1 user,  load average: 1.00, 1.00, 1.00

The above confirms that my ethernet woes are simply due to ethernet cable defect and not onboard hardware nor software.

I’ve previously manually set the Ethernet to run at 100 Mbps via ethtool -s eth0 speed 100 ,
but that it is unknown why it sticks to 100 Mbps. But for now I don’t think this is a defect, e.g. it could be due to my up stream hub etc. Hope that others who managed to run it (Ethernet) at 1 Gbps feedback on the same.

Orange Pi Zero 3 is up for the 2nd day running as a Wifi hotspot (on YT8531 ethernent at 100 Mbps and UWE5622 Wifi 5ghz 802.11ac) with the DietPi test image without ethernet completely freezing out and down.

DietPi wifi hotspot up for 3rd or 4th day running without ethernet freezing out and dropped. This is on the test images, everything else same as previous. That said, I’d need to mention that I’ve not tested many other stuff e.g. video (hdmi) and usb (e.g. keyboard), others should test it and feedback if they use them.

1 Like

Great that the onboard WiFi works good for you, since we have quite mixed reports. Good that the WiFi hotspot works as well (even in 5 GHz mode), I haven’t tested this.

Indeed, ethtool link speed should reset on reboot, isn’t it? There is a setting in dietpi-config to change it permanently, which is done via /etc/network/interface entry, triggering an ethtool drop-in config. But I guess you did not use that. Does ethtool -s eth0 speed 1000 change something? Of course it could be also the network it is connected to, but then all hosts on the network should run at 100 Mbps.