Sorry for not following the “script” but I’m writing on mobile and it would be quite tedious.
I have issues with WiFi on two boards: Orange Pi Zero 2 W and Raspberry Pi Zero 2 W. Latest dietpi (9.5), mostly a fresh install, updated to kernel 6.6 in case of rpi.
There are issues with ifup when booting (not with USB ethernet but only with WiFi). I’ve tested them more on Opi so this is what happens.
USB ethernet connected: ifup takes a few seconds, ethernet ifup succeeds fast, WiFi ifup tries to connect but usually does not work. The system boots.
No USB ethernet: sometimes the system boots without a WiFi connection (never manages to connect), sometimes ifup gets a “no time limit” timeout and does not want to ever boot. The only means to interact is the magic SysRq key. After a REISUB restart, it sometimes boots (again, never connects to WiFi).
The only way I managed to get WiFi to work is to (after booting): disable the wireless connection in dietpi-config, then re-enable it. Without fail, it always connects. I have yet to try this on rpi.
So there is no way to reliably boot the board and be able to ssh to it without a cable, other than: boot with ethernet enabled, disable/re-enable WiFi, disconnect the cable. I know there are problems with the spr... module that manages WiFi on opi, but if the answer is to unload and load it again, why not do it during the boot sequence?
Oh also sometimes booting fails because the udisks2 service doesn’t want to start (not sure if this is related).
I have been dealing with same issues it seems for weeks - let me ask you this- are you trying to use more than one active internet connection at the same time? I suspect : yes. Me too. (use wlan0 and eth0 simultaneously on same LAN)
DietPi “everyone” and Linux “everyone” immediately will ask (rather than respond to problem) “WHY WOULD YOU WANT TWO INTERFACES ON SAME LAN WORKING SIMULTANEOUSLY!?” Completely unhelpful.
What I have learned is that dietpi-config only sees 2 max adapters. Wlan0 and Eth0. The configs prefer eth0 to wlan0 and will make the eth0 default route, so when wlan0 comes up… or doesn’t… it’s because the default route on your system is through the eth0 interface.
This means you’re looping in wlan0 out eth0 in wlan0 etc… UNLESS …
you make a default route for only one interface OR
you assign a default route in the system for each interface and never use dietpi-config again for networking.
What’s nuts to me, maybe Ii dont get the DP philosophy, is taht alll SBC boards come with MULTIPLE interfaces and being able to use and access them by default in a home lab seems like the normal, typical use-case. IE if you’re screwing with wifi adapters / drivers and mess up you can still ssh to your eth0 and fix without dragging out cables and kvms etc to make a couple of line config changes and reboot and discover that you disconnected everythihng too soon and start smashing and throwing equipment like I have been doing lately.
So it seems like a few things need addressing here:
default route option in dietpi-config for active use of 1+ interfaces simultaneously
ditch dietpi for debian
make a hard coded default route and ditch dp-config forever
Hmm, from what you’re saying, what I actually never tried is to disable ethernet via dietpi-config and then try rebooting.
The problem is not routes but the interface not being able to connect. It works perfectly fine when I disable and re-enable the WiFi.
What I don’t understand is why the board sometimes doesn’t just ignore the lack of connectivity and boot.
I’m using 2 different connections only because WiFi doesn’t want to work out of the box. But I don’t really understand the priorities that dietpi assigns.
It would be nice to try a vanilla debian distribution but it does not exist (and armbian doesn’t work with a GUI on Opi zero 2w)
the interface depends on the routes to get anywhere - to the gateway, or to other devices, or to the internet. so your interface can be “up” and “connected” but not have a route to the internet. it’s just got an ip and physical connectivity.
I also noticed, if you have docker installed, and dont have a eth0 configured (like zeros, or for any other device / reason), it will default route to the docker0 as the “default interface” (you can tell when you log in to dietpi the MOTD header shows you lol)
this is so backward. You should be able to dp-config / network / default route with n+ interfaces configured. There is no reason not to have this option there if you force reconfigure crap every time you reboot dietpi.
in the dp-config, under advanced network options, you can set the machine to “wait for network to boot”’ or disable it. I always disable it because if you reboot and there isn’t instant connectivity, it will retry to to connect x# of times, waiting x# of secs between attempts, before failing it and moving on. Why bother? Just disable wait for network to boot. Same result either way. it will or wont work bbeause the config is or is not right, regardless if the wait for network detects connectvitiy or not.
armbian has a gui on opi - just sucks. lol. What you want the gui for? sucky desktop machine. better used as a headless server / docker app. Even a pi5 isn’t a good desktop replacement - no graphics ability for anything really but office crap or streaming video at most. All my sbc’s are headless. My imac has ubuntu only installed and I have android devices which are my “desktops”. The little sbcs are just “processors” for whatever so my computer doesn’t have to do it. It’s like thye are “agents” for you. You shouldnt need to gui access them except tthrough web / app interface once configured…
Debian is a text based system. Text configs too. what makes it different than others. Ubuntu is a debian distro, so it’s just enabled a fatter debian by adding tons of extran apps and drivers just in case, so you doont have to mess with command line or text ever. point click etc.
each has its place. configs, IMO, should be command line / text. I think debian does this right, though needs improvement still. configs all over the place. random names and conventions. not a platform as much as potential to be a platform.
just keep in mind, your interface can be up, and have right config, but if the default route (which you dont config in dietpi-config anywhere) is what determinse if anyone can get to your interface or if you can get out of your interface to anyone elses’.
Well, it’s not up and connected. I’ll send some console logs later so that you can see what happens.
As for using them with a GUI: thanks for the tip but I don’t need a server other than the one rpi4 that runs 24/7. These small SBCs are just to play around with. Sometimes using a desktop, sometimes not. Either way, this is not relevant.
Also I’m not sure why you’re trying to teach me about Ubuntu vs debian. Let’s keep on topic - how to get the board to boot and the WiFi to work.
my friend, I’m done here. You mentioned the want of a GUI. You want one, get ubuntu or something else.
you posted asking for help, in a community forum, and then didn’t wanat the help you got, didn’t want to post the “script” because it’s inconvenient for you… etc…
Your answer is posted above. Google “debian set default route” You are welcome.
No, I want to get Opi zero 2 w and rpi zero 2 w to boot and to connect to WiFi. Any discussion about GUIs is irrelevant.
Well, I’ll try to set the default route but I doubt it will do anything (because as I wrote above - WiFi works but only after unloading then loading the kernel module).
if you have to load / unload kernel modules, you may have the wrong driver.
but I doubt it… hard to tell since I dont have your “script”’ to know anything at all
all you’re doing loading / unloading modules is “ifup wlan0” “ifdown wlan0” etc…
just reboot does same thing.
again, iif your interfaces are correct configs, your route is the problem. if the driver is loaded and getting ap association, and ip address it’s probably not the driver.
maybe take 10 mins and go pet a dog, touch grass, step away, and get some space from the issue so you’re clear headed when you come back and not getting upset at people trying to help and sympathize with your troubles.
this is a common-unity forum (community). we want to help. we are here to help. we cant do it without one another. be kind in your replies. Your frustration is with an inanimate object that is outsmarting you. No one likes that.
As I said, there is no connection (no association). So routes are probably irrelevant. When it associates and connects, the WiFi works. There was never a situation in which there was an IP address but the network did not work.
The WiFi driver is not “mine”, it affects every user with these boards. This is why I am trying to troubleshoot it on a forum, where the fixes would percalate to everyone else too.
all relevant info that would have been nice to have up front.
I have no problems with the default drivers or devices and default config on dietpi. “zero” problems lol on orange pi zero 2w, zero3 4g, pi zero2w, none. all work fine default.
so sounds like you would benefit from a reinstall since it’s not a vital machine as you say, you just tinker with it. glad it’s something small and simple.
The system is quite fresh, less than 2 weeks old and I’ve not changed any of the network configuration so I don’t know what a reinstall would do. But yes, maybe it’s worth trying.
when you get setup again, and it works, clone your card before modifying anything. nice quick “ctrl+z” option. I definitely do that before I mess with modules or drivers and kernel. And, I like to have the ability to “get up and going asap” and then go back when I feel like it and try to solve the actual issue that came up. Cheers.
This way it works like a docker container - “docker restart dietpi”, just a manual method.
wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 40:b9:91:4a:ac:92 brd ff:ff:ff:ff:ff:ff
inet6 fe80::42b9:91ff:fe4a:ac92/64 scope link
valid_lft forever preferred_lft forever
Journalctl before the WiFi worked:
Booting:
Jun 18 13:16:46 opiz2w systemd[1]: Starting ifupdown-wait-online.service - Wait for network to be configured by ifupdown...
Jun 18 13:16:46 opiz2w systemd[1]: Starting ifupdown-pre.service - Helper to synchronize boot up for ifupdown...
Jun 18 13:16:48 opiz2w systemd[1]: Finished ifupdown-pre.service - Helper to synchronize boot up for ifupdown.
Jun 18 13:16:49 opiz2w systemd[1]: Starting ifup@eth0.service - ifup for eth0...
Jun 18 13:16:49 opiz2w systemd[1]: Starting ifup@wlan0.service - ifup for wlan0...
Jun 18 13:16:49 opiz2w systemd[1]: Finished ifup@eth0.service - ifup for eth0.
Jun 18 13:16:50 opiz2w systemd[1]: Finished ifupdown-wait-online.service - Wait for network to be configured by ifupdown.
Jun 18 13:17:06 opiz2w systemd[1]: Finished ifup@wlan0.service - ifup for wlan0.
Deactivation and activation:
Jun 19 21:47:50 opiz2w systemd[1]: Stopping ifup@wlan0.service - ifup for wlan0...
Jun 19 21:47:51 opiz2w systemd[1]: ifup@wlan0.service: Deactivated successfully.
Jun 19 21:47:51 opiz2w systemd[1]: Stopped ifup@wlan0.service - ifup for wlan0.
Jun 19 21:47:51 opiz2w systemd[1]: ifup@wlan0.service: Consumed 1.450s CPU time.
Jun 19 21:47:55 opiz2w systemd[1]: Stopping ifup@eth0.service - ifup for eth0...
Jun 19 21:47:56 opiz2w systemd[1]: ifup@eth0.service: Deactivated successfully.
Jun 19 21:47:56 opiz2w systemd[1]: Stopped ifup@eth0.service - ifup for eth0.
Jun 19 21:47:56 opiz2w systemd[1]: Starting ifup@eth0.service - ifup for eth0...
Jun 19 21:47:56 opiz2w systemd[1]: Finished ifup@eth0.service - ifup for eth0.
Jun 19 21:48:07 opiz2w systemd[1]: Starting ifup@wlan0.service - ifup for wlan0...
Jun 19 21:48:13 opiz2w systemd[1]: Stopping ifup@eth0.service - ifup for eth0...
Jun 19 21:48:15 opiz2w systemd[1]: ifup@eth0.service: Deactivated successfully.
Jun 19 21:48:15 opiz2w systemd[1]: Stopped ifup@eth0.service - ifup for eth0.
Jun 19 21:48:15 opiz2w systemd[1]: Starting ifup@eth0.service - ifup for eth0...
Jun 19 21:48:15 opiz2w systemd[1]: Finished ifup@eth0.service - ifup for eth0.
Jun 19 21:48:15 opiz2w ifup[3012]: ifup: failed to bring up wlan0
Jun 19 21:48:15 opiz2w systemd[1]: ifup@wlan0.service: Main process exited, code=exited, status=1/FAILURE
Jun 19 21:48:15 opiz2w systemd[1]: ifup@wlan0.service: Failed with result 'exit-code'.
Jun 19 21:48:15 opiz2w systemd[1]: Stopped ifup@wlan0.service - ifup for wlan0.
Jun 19 21:48:15 opiz2w systemd[1]: Starting ifup@wlan0.service - ifup for wlan0...
Jun 19 21:48:21 opiz2w systemd[1]: Finished ifup@wlan0.service - ifup for wlan0.
After this, the WiFi works:
wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 40:b9:91:4a:ac:92 brd ff:ff:ff:ff:ff:ff
inet 192.168.3.36/24 brd 192.168.3.255 scope global dynamic wlan0
valid_lft 86069sec preferred_lft 86069sec
inet6 fe80::42b9:91ff:fe4a:ac92/64 scope link
valid_lft forever preferred_lft forever
The next step is to disconnect the USB ethernet adapter, reboot and see if wireless still works.
And now it does not work. So my conclusion is that there is something wrong with dietpi when an ethernet adapter is not found - network does not work at all on boot then. @MichaIng could you take a look?
(huh, I restarted it again and now it is connected… Something is not stable at least)
again, this is a route problem. you have looping route. that’s why when you are connected to the eth0, (easy, default connection when both are configured and connected). You set up wireless it all looks good. You reboot and no wifi or eth0 (because you unplugged it). But dietpi still has that default route through your device. Out eth0
my opi zero is fine. it has eth0 built in and wifi built in like a regular pi. My pi Zeros that only have wifi, do exactly what you are describing when I try to connect any kind of usb adapter to the OTG cable, that has an ethernet port on it. That becomes the new eth0 and the onboard is ignored.
Make sense? Iit’s a dietpi config issue. It’s how they do the dietpi-config / networking. Everything I have read says it’s intended behavior, with the presumptioin that no normal person would ever need both wifi and eth0 enabled on the same lan connection.
Of course, this is restrictive and an assumption that seems poorly thought out, especially with sbc boards that are dual or more interfaces. it’d be nice to use them all at the same time or at least have the option, as this would be the “normal expected behavior” of any device.
Like ubuntu, I expect to plug in a usb wifi and it work, without disabling my others. And it does just that. No problem.
Dietpi is debian - for PI - but it doesnt do this . That strikes me as counter-fundamental and counter the purpose of “pi” in diet"pi". Be it orange banana or other fruits
for $15 get a “hat” with an eth0 and call it a day. Use both wifi and lan same time no problem. But delete your dietpi and reinstall first. You shouldn’t be getting that repeating updown crap just twice - one per interface - and whenever you tell it to up/down. or remove module and reenable.
If you want to feel like this “ISNT” a problem, try grabbing a usb wifi adapter and installing it and configuring it and having it work lol
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:
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
@MichaIng thanks for all your great, thorough explanations. I’m always better informed after.
I think a good “hold over fix” might be just some sort of notice of what is actually happening when you are changing network dietpi config. Llike the pihole popup for “static ip”. “IF you have two up interfaces on same network range, THEN this thing will happen. See link for details…”
Ii figured it out - like most things in my life - the hardest way. Try every single option until youre certain of the source lol and then adapt if you cant resolve.
for most who I’ve read having this problem with sbcs is that they are built to be tinkered with. And broken. and rebuilt. So you often find yourself without access and have to hook up gear to this tiny thing and adapters and it’s a real pain. I keep 2 interfaces up for this on OPiZ3 for a back door in. Services should be configed to an interface by ip or port so I dont see how it’d be a problem. If I’m calling .105 and .106 is on too, it does not care or listen or notice me.
perhaps a “default router” config can be scripted. For example if you detect multiple interfaces, you can offer to do a routing table. in if1 out if2 or separate vlans etc. it seems like a simple “fill in the #” series of questions or select from available interfaces. Simple right ? lol
yeah from my cisco days, routing is far simpler that it sounds - just in and out like any addressable interface. it’s agnostic to the # of interfaces. I think that’s ideal. You tell it what to do and it does it. even create fake interfaces. When I got into linux I discovered “oh this is all the same stuff”
