ok this is the default service and should be fine.
MichaIng
Any ideas why Wireguard is starting before WiFi becomes available?
It seems the network-online.target is reached before wpasupplicant fully finished. It gets “initialized” before but has not connected to the SSID yet. So the dietpi-wifi-monitor fails and restart the network.
Can you show:
systemctl cat ifup@wlan0
systemctl status wpasupplicant # should be disabled, started by ifup directly
To get a better overview:
journalctl -u ifup@wlan0 -u wg-quick@wg0 -u dietpi-wifi-monitor -u network-online.target -u network.target
Here you go:
root@DietPi:~# systemctl cat ifup@wlan0
# /lib/systemd/system/ifup@.service
[Unit]
Description=ifup for %I
After=local-fs.target network-pre.target apparmor.service systemd-sysctl.serviceBefore=network.target shutdown.target network-online.target
Conflicts=shutdown.target
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
DefaultDependencies=no
IgnoreOnIsolate=yes
[Service]
# avoid stopping on shutdown via stopping system-ifup.slice
Slice=system.slice
ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I'
ExecStop=/sbin/ifdown %I
RemainAfterExit=true
TimeoutStartSec=5min
# /etc/systemd/system/ifup@.service.d/dietpi.conf
...skipping 1 line
[Service]
Type=oneshot
ExecStart=
ExecStart=/sbin/ifup --allow=hotplug %I
root@DietPi:~# systemctl status wpasupplicant
Unit wpasupplicant.service could not be found.
root@DietPi:~# journalctl -u ifup@wlan0 -u wg-quick@wg0 -u dietpi-wifi-monitor -u network-online.target -u network.target
-- Logs begin at Tue 2022-03-22 06:17:09 CET, end at Thu 2022-03-24 06:38:37 CET. --
Mär 22 06:17:11 DietPi systemd[1]: Starting ifup for wlan0...
Mär 22 06:17:12 DietPi wpa_supplicant[329]: Successfully
initialized wpa_supplicant
Mär 22 06:17:12 DietPi systemd[1]: Started ifup for wlan0.
Mär 22 06:17:12 DietPi systemd[1]: Reached target Network.
Mär 22 06:17:12 DietPi systemd[1]: Reached target Network is Online.
Mär 22 06:17:12 DietPi systemd[1]: Started DietPi-WiFi_Monitor.
Mär 22 06:17:12 DietPi dietpi-wifi-monitor.sh[430]: [ INFO ] DietPi-WiFi_Monitor | Checking connection for wlan0 via ping to default gateway every 10 seconds
Mär 22 06:17:14 DietPi wpa_supplicant[373]: wlan0: Tryin
g to associate with SSID 'FRITZ!Box 4040 VN'
Mär 22 06:17:16 DietPi dietpi-wifi-monitor.sh[430]: [ INFO ] DietPi-WiFi_Monitor | Detected wlan0 connection loss. Reconnecting...
Mär 22 06:17:16 DietPi systemd[1]: Starting WireGuard via wg-quick(8) for wg0...Mär 22 06:17:16 DietPi wpa_supplicant[373]: wlan0: CTRL-
EVENT-DISCONNECTED bssid=2c:3a:fd:25:52:c2 reason=3 locally_generated=1
Mär 22 06:17:16 DietPi wpa_supplicant[373]: wlan0: CTRL-
EVENT-REGDOM-CHANGE init=CORE type=WORLD
Mär 22 06:17:16 DietPi wpa_supplicant[373]: wlan0: CTRL-
EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=GB
Mär 22 06:17:16 DietPi wpa_supplicant[373]: nl80211: Fai
led to open /proc/sys/net/ipv4/conf/p2p-dev-wlan0/drop_unicast_in_l2_multicast: No such file or directory
Mär 22 06:17:16 DietPi wpa_supplicant[373]: nl80211: Fai
led to set IPv4 unicast in multicast filter
Mär 22 06:17:16 DietPi wpa_supplicant[373]: nl80211: Fai
led to open /proc/sys/net/ipv4/conf/p2p-dev-wlan0/drop_unicast_in_l2_multicast: No such file or directory
Mär 22 06:17:16 DietPi wpa_supplicant[373]: nl80211: Fai
led to set IPv4 unicast in multicast filter
Mär 22 06:17:16 DietPi wpa_supplicant[373]: nl80211: dei
nit ifname=p2p-dev-wlan0 disabled_11b_rates=0
Mär 22 06:17:16 DietPi wg-quick[522]: [#] ip link add wg0 type wireguard
Mär 22 06:17:16 DietPi wpa_supplicant[373]: p2p-dev-wlan
0: CTRL-EVENT-TERMINATING
Mär 22 06:17:16 DietPi wg-quick[522]: [#] wg setconf wg0 /dev/fd/63
Mär 22 06:17:16 DietPi wg-quick[522]: [#] ip -4 address add 10.9.0.1/24 dev wg0
Mär 22 06:17:16 DietPi wg-quick[522]: [#] ip -6 address add fc00:9:0::1/64 dev wg0
Mär 22 06:17:16 DietPi wg-quick[522]: [#] ip link set mtu 1420 up dev wg0
Mär 22 06:17:16 DietPi wpa_supplicant[373]: nl80211: dei
nit ifname=wlan0 disabled_11b_rates=0
Mär 22 06:17:16 DietPi wg-quick[522]: [#] sysctl net.ipv4.conf.wg0.forwarding=1 net.ipv4.conf.$(ip r l 0/0 | mawk '{print $5;exit}').forwarding=1
Mär 22 06:17:16 DietPi wg-quick[522]: net.ipv4.conf.wg0.forwarding = 1
Mär 22 06:17:16 DietPi wg-quick[522]: sysctl: separators should not be repeated: ..forwarding
Mär 22 06:17:16 DietPi wg-quick[522]: sysctl: cannot stat /proc/sys/net/ipv4/conf//forwarding: No such file or directory
Mär 22 06:17:16 DietPi wg-quick[522]: [#] ip link delete dev wg0
Mär 22 06:17:16 DietPi wpa_supplicant[373]: wlan0: CTRL-
EVENT-TERMINATING
Mär 22 06:17:17 DietPi systemd[1]: wg-quick@wg0.service:
Main process exited, code=exited, status=255/EXCEPTION
Mär 22 06:17:17 DietPi systemd[1]: wg-quick@wg0.service:
Failed with result 'exit-code'.
Mär 22 06:17:17 DietPi systemd[1]: Failed to start WireG
uard via wg-quick(8) for wg0.
Mär 22 06:17:17 DietPi wpa_supplicant[692]: Successfully
initialized wpa_supplicant
Mär 22 06:17:18 DietPi dietpi-wifi-monitor.sh[430]: [ OK ] DietPi-WiFi_Monitor | Completed
Mär 22 06:17:20 DietPi wpa_supplicant[701]: wlan0: Tryin
g to associate with SSID 'FRITZ!Box 4040 VN'
Mär 22 06:17:23 DietPi wpa_supplicant[701]: RRM: Ignorin
g radio measurement request: Not associated
Mär 22 06:17:23 DietPi wpa_supplicant[701]: wlan0: Assoc
iated with 2c:3a:fd:25:52:c1
Mär 22 06:17:23 DietPi wpa_supplicant[701]: wlan0: CTRL-
EVENT-CONNECTED - Connection to 2c:3a:fd:25:52:c1 completed [id=0 id_str=]
Mär 22 06:17:23 DietPi wpa_supplicant[701]: wlan0: CTRL-
EVENT-SUBNET-STATUS-UPDATE status=0
Mär 22 06:17:23 DietPi wpa_supplicant[701]: wlan0: CTRL-
EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
Mär 22 06:17:23 DietPi wpa_supplicant[701]: RRM: Ignorin
g radio measurement request: Not RRM network
Mär 22 06:19:24 DietPi dietpi-wifi-monitor.sh[430]: [ INFO ] DietPi-WiFi_Monitor | Detected wlan0 connection loss. Reconnecting...
Mär 22 06:19:25 DietPi wpa_supplicant[701]: wlan0: CTRL-
EVENT-DISCONNECTED bssid=2c:3a:fd:25:52:c1 reason=3 locally_generated=1
Mär 22 06:19:25 DietPi wpa_supplicant[701]: wlan0: CTRL-
EVENT-REGDOM-CHANGE init=CORE type=WORLD
Mär 22 06:19:25 DietPi wpa_supplicant[701]: wlan0: CTRL-
EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=GB
Mär 22 06:19:25 DietPi wpa_supplicant[701]: nl80211: Fai
led to open /proc/sys/net/ipv4/conf/p2p-dev-wlan0/drop_unicast_in_l2_multicast: No such file or directory
Mär 22 06:19:25 DietPi wpa_supplicant[701]: nl80211: Fai
led to set IPv4 unicast in multicast filter
Mär 22 06:19:25 DietPi wpa_supplicant[701]: nl80211: Fai
led to open /proc/sys/net/ipv4/conf/p2p-dev-wlan0/drop_unicast_in_l2_multicast: No such file or directory
Mär 22 06:19:25 DietPi wpa_supplicant[701]: nl80211: Fai
led to set IPv4 unicast in multicast filter
Mär 22 06:19:25 DietPi wpa_supplicant[701]: nl80211: dei
nit ifname=p2p-dev-wlan0 disabled_11b_rates=0
Mär 22 06:19:25 DietPi wpa_supplicant[701]: p2p-dev-wlan
0: CTRL-EVENT-TERMINATING
Mär 22 06:19:25 DietPi wpa_supplicant[701]: nl80211: dei
nit ifname=wlan0 disabled_11b_rates=0
Mär 22 06:19:25 DietPi wpa_supplicant[701]: wlan0: CTRL-
EVENT-TERMINATING
Mär 22 06:19:26 DietPi wpa_supplicant[1593]: Successfull
y initialized wpa_supplicant
Mär 22 06:19:26 DietPi dietpi-wifi-monitor.sh[430]: [ OK ] DietPi-WiFi_Monitor | Completed
Mär 22 06:19:29 DietPi wpa_supplicant[1596]: wlan0: Tryi
ng to associate with SSID 'FRITZ!Box 4040 VN'
Mär 22 06:19:31 DietPi wpa_supplicant[1596]: RRM: Ignori
ng radio measurement request: Not associated
Mär 22 06:19:31 DietPi wpa_supplicant[1596]: wlan0: Asso
ciated with 2c:3a:fd:25:52:c1
Mär 22 06:19:31 DietPi wpa_supplicant[1596]: wlan0: CTRL
-EVENT-CONNECTED - Connection to 2c:3a:fd:25:52:c1 completed [id=0 id_str=]
Mär 22 06:19:31 DietPi wpa_supplicant[1596]: wlan0: CTRL
-EVENT-SUBNET-STATUS-UPDATE status=0
Mär 22 06:19:31 DietPi wpa_supplicant[1596]: wlan0: CTRL
-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
Mär 22 06:19:31 DietPi wpa_supplicant[1596]: RRM: Ignori
ng radio measurement request: Not RRM network
Mär 22 06:19:32 DietPi wpa_supplicant[1596]: wlan0: Asso
ciated with 2c:3a:fd:25:52:c2
Mär 22 06:19:32 DietPi wpa_supplicant[1596]: wlan0: CTRL
-EVENT-CONNECTED - Connection to 2c:3a:fd:25:52:c2 completed [id=0 id_str=]
Mär 22 06:19:32 DietPi wpa_supplicant[1596]: wlan0: CTRL
-EVENT-SUBNET-STATUS-UPDATE status=0
Mär 22 06:19:41 DietPi wpa_supplicant[1596]: RRM: Ignori
ng radio measurement request: Not RRM network
Mär 22 06:19:41 DietPi wpa_supplicant[1596]: RRM: Ignori
ng radio measurement request: Not RRM network
Mär 22 06:20:10 DietPi wpa_supplicant[1596]: RRM: Ignori
ng radio measurement request: Not RRM network
Mär 22 06:20:10 DietPi wpa_supplicant[1596]: RRM: Ignori
ng radio measurement request: Not RRM network
Mär 22 06:20:48 DietPi systemd[1]: Starting WireGuard via wg-quick(8) for wg0...Mär 22 06:20:49 DietPi wg-quick[1799]: [#] ip link add wg0 type wireguard
Mär 22 06:20:49 DietPi wg-quick[1799]: [#] wg setconf wg0 /dev/fd/63
Mär 22 06:20:49 DietPi wg-quick[1799]: [#] ip -4 address add 10.9.0.1/24 dev wg0Mär 22 06:20:49 DietPi wg-quick[1799]: [#] ip -6 address add fc00:9:0::1/64 dev wg0
Mär 22 06:20:49 DietPi wg-quick[1799]: [#] ip link set mtu 1420 up dev wg0
Mär 22 06:20:49 DietPi wg-quick[1799]: [#] sysctl net.ipv4.conf.wg0.forwarding=1 net.ipv4.conf.$(ip r l 0/0 | mawk '{print $5;exit}').forwarding=1
Mär 22 06:20:49 DietPi wg-quick[1799]: net.ipv4.conf.wg0.forwarding = 1
Mär 22 06:20:49 DietPi wg-quick[1799]: net.ipv4.conf.wlan0.forwarding = 1
Mär 22 06:20:49 DietPi wg-quick[1799]: [#] sysctl net.ipv6.conf.$(ip r l 0/0 | mawk '{print $5;exit}').accept_ra=2
Mär 22 06:20:49 DietPi wg-quick[1799]: net.ipv6.conf.wlan0.accept_ra = 2
Mär 22 06:20:49 DietPi wg-quick[1799]: [#] sysctl net.ipv6.conf.wg0.forwarding=1 net.ipv6.conf.$(ip r l 0/0 | mawk '{print $5;exit}').forwarding=1
Mär 22 06:20:49 DietPi wg-quick[1799]: net.ipv6.conf.wg0.forwarding = 1
Mär 22 06:20:49 DietPi wg-quick[1799]: net.ipv6.conf.wlan0.forwarding = 1
Mär 22 06:20:49 DietPi wg-quick[1799]: [#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o $(ip r l 0/0 | mawk '{print $5;exit}') -j MASQUERADE
Mär 22 06:20:49 DietPi wg-quick[1799]: [#] ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o $(ip r l 0/0 | mawk '{print $5;exit}') -j MASQUERADE
Mär 22 06:20:49 DietPi systemd[1]: Started WireGuard via wg-quick(8) for wg0.
Mär 22 06:22:16 DietPi wpa_supplicant[1596]: RRM: Ignori
ng radio measurement request: Not RRM network
Mär 22 06:22:16 DietPi wpa_supplicant[1596]: RRM: Ignori
ng radio measurement request: Not RRM network
Mär 22 07:00:04 DietPi wpa_supplicant[1596]: RRM: Ignori
ng radio measurement request: Not RRM network
Mär 22 07:00:04 DietPi wpa_supplicant[1596]: RRM: Ignori
ng radio measurement request: Not RRM network
Mär 22 07:02:10 DietPi wpa_supplicant[1596]: RRM: Ignori
ng radio measurement request: Not RRM network
Mär 22 07:02:10 DietPi wpa_supplicant[1596]: RRM: Ignori
ng radio measurement request: Not RRM network
Mär 22 07:04:42 DietPi wpa_supplicant[1596]: RRM: Ignori
ng radio measurement request: Not RRM network
Mär 22 07:04:54 DietPi wpa_supplicant[1596]: RRM: Ignori
ng radio measurement request: Not RRM network
Mär 22 07:21:26 DietPi wpa_supplicant[1596]: RRM: Ignori
ng radio measurement request: Not RRM network
Ah sorry, the one command should have been:
systemctl status wpa_supplicant
So indeed the network-online.target is reached after wpa_supplicant first reports a successful initialization, but is seems to have not really finished connecting to the SSID, it also reports a failure before it really finishes. When the target is reached, all network services, including the DietPi WiFi monitor, start, and one of the problems seems that it detects a connection loss (makes sense since WiFi is not yet fully there) and hence restarts the wlan0 interface.
Let’s first see with above command whether the intended ifup controlled wpa_supplicant process is starting. I’ll check on my systems whether the network-online.target is commonly reached while wpa_supplicant is still processing. If so, we may need to add 10s sleep or so to the WiFi monitor on initial start, to assure it does not interfere the full WiFi initialization. To rule this out you may also test whether the issue persists is your disable it:
systemctl disable dietpi-wifi-monitor
reboot
The output as per your request:
root@DietPi:~# systemctl status wpa_supplicant
● wpa_supplicant.service - WPA supplicant
Loaded: loaded (/lib/systemd/system/wpa_supplicant.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Test results follow…
root@DietPi:~# journalctl -u ifup@wlan0 -u wg-quick@wg0 -u dietpi-wifi-monitor -u network-online.target -u network.target
-- Logs begin at Thu 2019-02-14 11:11:59 CET, end at Thu 2022-03-24 19:19:31 CET. --
Mär 24 19:17:55 DietPi systemd[1]: Starting ifup for wlan0...
Mär 24 19:17:56 DietPi wpa_supplicant[331]: Successfully initialized wpa_supplicant
Mär 24 19:17:56 DietPi systemd[1]: Started ifup for wlan0.
Mär 24 19:17:56 DietPi systemd[1]: Reached target Network.
Mär 24 19:17:56 DietPi systemd[1]: Reached target Network is Online.
Mär 24 19:17:58 DietPi wpa_supplicant[374]: wlan0: Trying to associate with SSID 'FRITZ!Box 4040 VN'
Mär 24 19:18:01 DietPi wpa_supplicant[374]: wlan0: Associated with 2c:3a:fd:25:52:c1
Mär 24 19:18:01 DietPi wpa_supplicant[374]: wlan0: CTRL-EVENT-CONNECTED - Connection to 2c:3a:fd:25:52:c1 completed [id=0 id_str=]
Mär 24 19:18:01 DietPi wpa_supplicant[374]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Mär 24 19:18:01 DietPi wpa_supplicant[374]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
Mär 24 19:18:02 DietPi systemd[1]: Starting WireGuard via wg-quick(8) for wg0...Mär 24 19:18:02 DietPi wg-quick[537]: [#] ip link add wg0 type wireguard
Mär 24 19:18:02 DietPi wg-quick[537]: [#] wg setconf wg0 /dev/fd/63
Mär 24 19:18:02 DietPi wg-quick[537]: [#] ip -4 address add 10.9.0.1/24 dev wg0
Mär 24 19:18:02 DietPi wg-quick[537]: [#] ip -6 address add fc00:9:0::1/64 dev wg0
Mär 24 19:18:02 DietPi wg-quick[537]: [#] ip link set mtu 1420 up dev wg0
Mär 24 19:18:02 DietPi wg-quick[537]: [#] sysctl net.ipv4.conf.wg0.forwarding=1 net.ipv4.conf.$(ip r l 0/0 | mawk '{print $5;exit}').forwarding=1
Mär 24 19:18:02 DietPi wg-quick[537]: net.ipv4.conf.wg0.forwarding = 1
Mär 24 19:18:02 DietPi wg-quick[537]: net.ipv4.conf.wlan0.forwarding = 1
Mär 24 19:18:02 DietPi wg-quick[537]: [#] sysctl net.ipv6.conf.$(ip r l 0/0 | mawk '{print $5;exit}').accept_ra=2
Mär 24 19:18:02 DietPi wg-quick[537]: net.ipv6.conf.wlan0.accept_ra = 2
Mär 24 19:18:02 DietPi wg-quick[537]: [#] sysctl net.ipv6.conf.wg0.forwarding=1 net.ipv6.conf.$(ip r l 0/0 | mawk '{print $5;exit}').forwarding=1
Mär 24 19:18:02 DietPi wg-quick[537]: net.ipv6.conf.wg0.forwarding = 1
Mär 24 19:18:02 DietPi wg-quick[537]: net.ipv6.conf.wlan0.forwarding = 1
Mär 24 19:18:02 DietPi wg-quick[537]: [#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o $(ip r l 0/0 | mawk '{print $5;exit}') -j MASQUERADE
Mär 24 19:18:03 DietPi wg-quick[537]: [#] ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o $(ip r l 0/0 | mawk '{print $5;exit}') -j MASQUERADE
Mär 24 19:18:03 DietPi systemd[1]: Started WireGuard via wg-quick(8) for wg0.
Mär 24 19:18:15 DietPi wpa_supplicant[374]: RRM: Ignoring radio measurement request: Not RRM network
Mär 24 19:18:16 DietPi wpa_supplicant[374]: RRM: Ignoring radio measurement request: Not RRM network
Mär 24 19:18:16 DietPi wpa_supplicant[374]: RRM: Ignoring radio measurement request: Not RRM network
Mär 24 19:18:16 DietPi wpa_supplicant[374]: wlan0: Associated with 2c:3a:fd:25:52:c2
Mär 24 19:18:16 DietPi wpa_supplicant[374]: wlan0: CTRL-EVENT-CONNECTED - Connection to 2c:3a:fd:25:52:c2 completed [id=0 id_str=]
Mär 24 19:18:16 DietPi wpa_supplicant[374]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Mär 24 19:18:21 DietPi wpa_supplicant[374]: RRM: Ignoring radio measurement request: Not RRM network
Mär 24 19:18:22 DietPi wpa_supplicant[374]: RRM: Ignoring radio measurement request: Not RRM network
Disabling the WiFi monitor seems to have solved the issue. Wireguard works without a manual restart.
thx for sharing, we will have a look.
It’s bad that network-online target is reached before wpa_supplicant has fully finished, but this is how it is on my systems as well: The “successful initialization” is sufficient, while this doesn’t meant that connectivity is really there. This is different with the DHCP client, which really must finish an initial lease or time out before the target is reached, so having DHCP server enabled solves the issue as well (while of course I always recommend a static IP for a server system).
Indeed DietPi-WiFi-Monitor starts too early for the same reason and since connectivity isn’t there yet, it does a network interface restart, which breaks WireGuard startup. A 10 seconds grace time should solve it.
Interesting however is that WireGuard starts after wpa_supplicant has really finished, and I’m wondering if this is just a coincidence or whether there is a reason behind it:
After=network-online.target nss-lookup.target
https://www.freedesktop.org/software/systemd/man/systemd.special.html#nss-lookup.target
WireGuard does something wrong here:
Note specifically that these passive target units are generally not pulled in by the consumer of a service, but by the provider of the service. This means: a consuming service should order itself after these targets (as appropriate), but not pull it in.
Means the target has no meaning without a service that actively “provides” it, like Unbound, dnsmasq and other DNS resolvers do.
Another issue on one of my devices is that the WiFi adapter is detected (the udev “add” event triggers) after network-online.target has been reached already. This happens only on one of my old notebooks, but that it is generally possible for hardware to be detected so late while boot has finished already is of course bad. Interestingly this is not an issue when not bringing up the interface on device detection but right away (auto wlan0 vs allow-hotplug wlan0), which is somehow impossible since bringing up an interface of course cannot succeed when the device has not been detected yet. Enabling udev debug logging, I see
systemd-udevd[167]: wlan0: Running command “ifupdown-hotplug”
before network interfaces are being configured, so actually the device is available. The only left explanation is that /lib/udev/ifupdown-hotplug execution takes too long to tsart ifup@wlan0 service, so that …
… found it:
2022-03-26 15:53:10 root@emachines:~# systemctl cat ifupdown-pre
# /lib/systemd/system/ifupdown-pre.service
[Unit]
Description=Helper to synchronize boot up for ifupdown
DefaultDependencies=no
Wants=systemd-udevd.service
After=systemd-udev-trigger.service
Before=network.target
[Service]
Type=oneshot
TimeoutSec=180
RemainAfterExit=yes
EnvironmentFile=-/etc/default/networking
ExecStart=/bin/sh -c 'if [ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && [ -x /bin/udevadm ]; then udevadm settle; fi'
# /etc/systemd/system/ifupdown-pre.service.d/micha.conf
[Service]
ExecStart=
ExecStart=/bin/dash -c '[ "$CONFIGURE_INTERFACES" = "no" ] || [ ! -x /bin/udevadm ] || udevadm settle'
Above the original unit:
- ifquery --read-environment --list --exclude=lo doesn’t show “allow-hotplug” interface, hence udevadm settle is not executed so that network targets can be reached while udev events are still running.
- Taking away this condition solves the issue, network targets are now reached after udev has settled and hence ifup@wlan0 is starting and finished and respected for network-online.target to be reached as well.
- Somehow strange that allow-hotplug interfaces are ignored here, since especially those rely on udev events to happen (interfaces to be detected) for network targets to have any meaning. Also having this “udevadm settle” running without any network interface configured at all is not an issue since then (without network) there is no service relying on network anyway, where one might want to avoid this being delayed unnecessarily. It’s the same as with ifup@.service being “Type=simple” on Debian, so that network-online.target can be reached before interface configuration finished, which we already change in DietPi. Somehow Debian actively prevents allow-hotplug interfaces from having any effect on boot sequence and network targets while on the other hand this is often the default and recommended way of configuring interfaces to assure that slow hardware is still configured and unplugged hardware does not break networking targets.
I’ll add the above override for DietPi v8.3 which should synchronize network targets with allow-hotplug interfaces with auto-interfaces, again fixing the meaning of network-online.target for certain cases.
Solved with: https://github.com/MichaIng/DietPi/commit/a7476fc
I only understand part of your analysis (if anything) and appreciate your effort very much.
There is a reason why I am a user and you the experts 
Thank you both!
I’m also documenting finds for myself by times . In shorter: The way we setup network interfaces implies that network targets, used to sort systemd service start-ups, do not wait for all hardware devices to be detected. So services which are instructed to wait for network, by ordering them after network targets, could have started before network adapters were detected. With the above change it is assured that network targets are never reached before attached network adapters have been detected, which solves the main reason for your issue. Additionally the WiFi monitor now waits for 10 seconds before doing the first connection check, to give WiFi interfaces additional time at boot to gain full connectivity to the access point. Previously the first connectivity check was done immediately and the first 10 seconds were waited only after that first check and possible WiFi restart.