I ran into this nightmare configuring a Dell Edge GW as an AP, using the package hostapd. When Googling I saw lots of folks complaining about soft blocks when configuring an AP in various forums. Various different hacks were offered as work-arounds, but none of the posts really identified the root cause of soft blocks. After lengthy analysis I found how it was breaking.
Although some parts of the below answer are specific to the Dell Edge / hostapd config, it's still worth reading as it gives great insight into how/why a soft block is thrown.
Short Answer: Soft blocks occur when processes collide accessing radio
ie: NetworkManager is using the radio because it controls the GSM wwan0 interface. But when hostapd tries to access the radio via the wlan0 IF which is NOT managed by NetworkManager because they don't play well with each other- they come into conflict. NetworkManager greedily covets the radio and if anything else tries to use it, NetworkManager spitefully throws a soft block
Although the solution may sound obvious- uniformly manage radio access within one interface management system- this is not so straight forward:
- NetworkManager as noted above is to be avoided when using hostapd
- systemd-networkd can neither be used with hostapd. After realizing NM couldn't be used to manage the wlan0 interface, when I tried to config systemd-networkd instead, I found that wouldn't work either: ERROR: wlan0: networkd does not support wifi in access point mode
When using hostapd for your AP, the WiFi IF (usually wlan0) should be raised using
ip commands AFTER and NM finished (and ensure nothing else restarts NM). I found doing a
rfkill unblock all before and after raising the wlan0 IF with scrripted IP commands cleared the soft block allowing the wlan0 IF to start correctly which inturn allowed hostapd to start normally on reboot.
Some specifics as to how I arrived at my conclusions in the short answer above.
IF Management: For their Edge gateway, Dell has enabled in their 18.04 image BOTH systemd-networkd AND NetworkManager, but in Netplan defaulted the IF management to the later. You'll remark a standard 18.04 install only has systemd-networkd as the default for IF management.
The wrapper for configuring an AP with hostapd "create_AP", unhooks the WiFi interface from NM control and uses
ip link set commands to raise the WiFi IF (line #1697 in above link). Although "_create_ap)" was part of Dell's 16.04 image, it's no longer present in the 18.04 image leaving the user to manually config the AP. This is where the fun begins
Having configured the GSM interface wwan0 successfully within NM, I configured the WiFi IF wlan0 in NM also. This failed for the same reasons "create_ap" and Arch Linux unhook it as I later found in the prev referenced links for NM. So per the Arch Linux instructions, I added the directive
unmanaged-devices=mac:<hwaddr> for the wlan0 in
/etc/NetworkManager/NetworkManager.conf to ensure NM didn't cause any further havoc with it.
Realizing NM was a non-starter for configuring hostapd, I next configured the wlan0 IF to be managed by systemd-networkd. However, the following error puked revealed that wouldn't work with hostapd either: ERROR: wlan0: networkd does not support wifi in access point mode. I was quickly losing the will to live. Had I not turned in my Glock when I left NYPD I probably would have self-harmed...
Neither NM or systemd-networkd being an option to manage the wlan0 interface, I was only left to configured it
ip commands. And this worked- MANUALLY. However, on reboot, the soft block was thrown, despite unhooking wlan0 from NM. So if NM isn't throwing the soft blocks now, what is?!?!?
Further analysis revealed NM was still in play. I found dhcpcd.service had a NM hook when it started, so a restart of the dhcpcd client would get NM rearing it's ugly head.
ps aux revealed this was happening:
/sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /run/dhclient-eth0.pid
I discovered that anything that caused NM to kick-in would cause the soft block to be thrown. So in my scripts I removed anything that called for NM to restarted or anything that called for dhcpcd.service to be restarted. But yet the problem STILL PERSISTED.
Although manually raising the wlan0 IF succeeded in allowing hostapd to rise-up correctly, a reboot caused the soft block which will stop the wlan0 IF from starting until it's cleared.
So the only solution I was able to arrive at was to raise the wlan0 IF AFTER NM had finished and ensure nothing else restarted NM once wlan0 was up. In my scripts I added a
rfkill unblock all both before and after the start of the
wlan0 IF using
ip commands. THIS FINALLY WORKED.
You might think: "Terrence, why not try to moderate the behaviour of dhcpcd.service in its' unit file rather than hacking in scripts!" Preferring elegant solutions to hacks, I looked into this: it's not possible to persistently edit that dhcpcd.service as the file is dynamically generated and doesn't persist across reboots!! Execute
find / -name dhcpcd.service and you'll see the unit files describing this service exist in /run. Crack one open and you'll be told: # Automatically generated by systemd-sysv-generator
Commands I scripted to stop NM from hogging the radio :
sed -i "/managed=true/a unmanaged-devices=interface-name:$INTERFACEAP" /etc/NetworkManager/NetworkManager.conf
nmcli radio wifi off
Commands I scripted to raise the wlan0 IF using IP commands, independent of both NM and systemd-networkd:
rfkill unblock all
ip addr add $IPV4IPWLAN0 dev $INTERFACEAP
ip link set $INTERFACEAP up
rfkill unblock all
Although I've got hostapd finally working, I'm going to therapy 7 days a week now and my therapist says I'm progressing well to get over the experience. Anyhoo, hope I saved others from this living hell...