Please keep the Raspberry Pi Zero 2 and the Orange Pi Zero 2W separate, since they are very different SBCs with very own difficulties.
First of all, yes, dietpi-config
does not handle 2 interfaces gracefully. It basically tries to configure each as Internet facing interface with default route, which usually naturally conflicts. So to rule out that part, please try to disable Ethernet and WiFi respectively, and check whether the other one then works as intended. If you really need to configure both, Ethernet and WiFi simultaneously, then note that you naturally cannot have a default route for both of them, or at least it is then just a matter of RNG whether it works or not, whether the system consistently sends requests trough one interface, or randomly through one and the other, breaking communication. So in this case, better configure the Internet facing adapter with dietpi-config
and the other one with an own config in /etc/network/interfaces.d
, the way you need it. Usually, if one adapter is for Internet access, the other one is to share access to LAN, as hotspot/AP or similar, in which case you do not want to have a gateway
configured, but an IP only. If it shall be a WiFi hotspot, then dietpi-software
has an installation option to setup both, Ethernet and WiFi + DHCP server and hostapd
correctly. There are plans for a new dietpi-network
script, which shall allow to configure every interface/adapter individually, including eth1
, eth2
etc if present, one as Internet facing adapter, the others static, with or without DHCP server and hotspot/AP functionality or bridge. However, there are more tasks then development time, hence I am not sure when I or someone else will finally find time to implement/finalise it.
For the Orange Pi Zero 2, it is known that WiFi cannot be disabled and enabled within the same session. The module for some reason then fails to load. So after having it enabled, it needs to be rebooted. I will implement some change for this, so that the module is loaded on first boot of a freshly flashed image, and WiFi hence can be configured directly, and otherwise dietpi-config
to show an info that a reboot is required. And apart of this, the Zero 2W sadly is currently quite unstable in general. Not sure why, but compared to the Zero 3, the device tree seems to be very crappy. You can just switch to the Zero 3 device tree, and the Zero 2W will work much better. Just some GPIO features won’t work.
For the Raspberry Pi Zero 2 and all Raspberry Pi’s it is similar, but well implemented already: WiFi can be configured on first boot. But when it was disabled, the system rebooted, then re-enabled, the system needs to be rebooted again. The reason is that we use a device tree overlay to disable WiFi kernel-wise. And those cannot be loaded/unloaded without a reboot.
So much for the background. Since the last posts are about the Orange Pi Zero 2W, let’s concentrate on that one, and the RPi Zero 2 in a new threat.
@urostor
Do I understand it right, that WiFi does work in your case, after disabling and re-enabling it? That would be new: Image | Orange Pi Zero 2W · Issue #6827 · MichaIng/DietPi · GitHub
Or did you not really disable it, but just re-applied the WiFi settings? Then the kernel module would not be unloaded, so that should work.
That bringup fails with Ethernet enabled simultaneously, might indeed have to do with it trying to apply a default route, while there is one applied for Ethernet already. I am currently not sure how this is handled. However, that it works when Ethernet is disabled seems to verify it. Please try to edit /etc/network/interface
and remove the gateway
line from either the wlan0
block or the eth0
block. And if not the case yet, switch the interface without gateway
from inet dhcp
to inet static
, else the DHCP client tries to assign the gateway.
Probably disabling the broken WiFi interface removes the gateway which was assigned by ifup@eth0
, so that re-enabling WiFi can then assign a new default gateway, and hence succeed.
Did you also disable Ethernet in dietpi-config
before disconnecting the adapter? Although, it should not matter, since we use allow-hotplug
interfaces, which are not configured until the adapter has been attached/detected. So yeah, I guess that WiFi failed one time might be the general instability of this SBC with its device tree. You can try the one for the Zero 3:
G_CONFIG_INJECT 'fdtfile=' 'fdtfile=allwinner/sun50i-h618-orangepi-zero3.dtb' /boot/dietpiEnv.txt
reboot
This also enables/fixes some other things, like HDMI audio and when using the analogue audio HAT, IIRC.
Ah, @bjmurrey I should have read your posts first, yes, well explained with the route problem. Though, since the gateway
is configured per-interface (which actually does not make any sense, since there cannot be 2 default routes, but this is how /etc/network/interfaces
works), when you just detach an adapter, the system will get the “correct” default route that was configured for the other/attached adapter, respectively what the DHCP client receives. So there really only should be an issue when two adapters are attached and both interfaces are configured with a gateway
or DHCP configured each, in which case either one of them fails to be configured, or you get a routing issue. Also, when one of the interfaces is configured without gateway, but is connected to the same network (same IP range), then you still have two conflicting link scope routes. I am not sure whether there is any use case and possibility to have two adapters connected to and configured for the same network. It would work when not configuring any route for one of the adapter, but then it is practically unused, which does not make sense.
If it is wanted to have e.g. Ethernet as fallback for WiFi, or the other way round, both Internet facing on the same network, then there should be some ifplugd
based (or similar) toggle, to have the offline adapter disabled before the fallbck is enabled: Using ethernet + WLAN interfaces (not at the same time) in v6.30