I can’t make AP work on a Rock Pi 4C+ with NetworkManager.
I can see the AP, but when I try to connect it is endlessly trying but nothing happens.
Is it the wrong drivers?
DietPi don’t use NetworkManager, as it is conflcting with ifupdown. So you seems to have it installed on your own. At least our tools don’t support NetworkManager. All configs would need to be done manually in this case.
Yes! Using networkmanager as it speed up boot a lot.
Regular WiFi and Ethernet seems to work out of the box with networkmanager. Just not AP.
Usually you would need to install some hotspot software like hostapd and if needed a DHCP server.
Ok! But using ifupdown would not work with AP out of the box? Because I tried using hostapd and dnsmasq, and that did not work. Seems like the Radxa Rock 4C+ drivers are not complete?
You would need to check if the WiFi adapter supports AP mode.
Running iw list shows this:
Supported interface modes:
* IBSS
* managed
* AP
* P2P-client
* P2P-GO
* P2P-device
It seems to run this driver:
driver: brcmfmac
version: 7.45.69
firmware-version: 01-24037f6e
When I tested AP yesterday it shows up, but I can never connect, it just tries forever.
Seems like something is wrong with AP and this driver?
It seems to support AP mode. Did you tried to install hotspot from dietpi-software while using ifupdown? This should configure everything needed
Will have to try that!
Is there a reason ifupdown is much slower to boot? Doesn’t matter if I set Boot wait for network to Off. It still adds about 3-4 seconds to boot compared to Networkmanager.
You would need to compare the boot process to see which service might take longer. And if identified, check the service log for the service taking longer.
Is an hours-long config hustle and trial and error worth the the 3 seconds faster boot? IMO idk 
Heh, so WiFi otherwise does work well? Or did you not test it, and AP does not work because WiFi does not work at all? See the other report here: Dietpi installation on Rock4C Plus - #16 by Marco
Let’s test things carefully, with plain DietPi using ifupdown, with Bluetooth disabled at first, just WiFi. If that does not work, no need to dig into AP.
This “Boot wait for network” option has not really much effect. Should be probably clarified in the menu: It delays only the dietpi-postboot.service which anyway asynchronously triggers dietpi-update check or network time sync respectively, and executes scripts in /var/lib/dietpi/postboot.d if any are present. And it shows the pre-login banner on the local console, which requires network only since is shows the LAN IP address. However, login prompts can appear before that, and everything else. This service does not delay anything else, and it is not critical for any other service startup, SSH or other login methods, and hence also not dietpi-autostart options.
Which part of the boot you mean in particular with the 3-4 seconds, and how do you measure it? We do some adjustments to ifupdown-pre.service and ifup@.service to give the network-online.target more meaning. This can delay services that order themselves after network targets. However, systemd init runs everything asynchronously which is not explicitly ordered, and e.g. a delayed web service has no impact on login prompts etc. You can check the critical boot chain like that:
systemd-analyze critical-chain
However, e.g. login prompts are ordered only after those units:
After=basic.target sysinit.target plymouth-quit-wait.service rc-local.service system-getty.slice getty-pre.target systemd-user-sessions.service
So if you do not see any of these after (above) a network-related target or service in the critical chain, they are not delayed by it.
The other way round, NetworkManager might just be ordered into the boot procedure a way that the network.target and network-online.target are reached right after NetworkManager started, but not after it actually finished configuring the network interface. So e.g. the SSH server might start earlier, but you cannot connect earlier, since network is not up yet.