I have to issue "rfkill unblock wifi" at every boot

Question

Config: Laptop, standard working wifi card, Ubuntu 14.04

At every boot, Wifi/Wlan is off/SoftBlocked, I can get it to work with the command sudo rfkill unblock wifi

but after every reboot I have to re-issue that command again (actually that's not entirely true, sometimes (5%) it seems to "stick" through a reboot).

Is there a way to tell rfkill to never block wifi, without having to tell it so explicitly every time?

Solution 1

You can make a service to do this. Execute the following command:

sudo nano /etc/systemd/system/rfkill-unblock-wifi.service

then, copy and paste the following into the file:

[Unit]
Description=RFKill-Unblock WiFi Devices

[Service]
Type=oneshot
ExecStart=/usr/sbin/rfkill unblock wifi
ExecStop=
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Press CTRL + o and then press ENTER to save the file. Press CTRL + x to exit nano.

Finally, execute the following command to enable start up the service:

sudo systemctl enable rfkill-unblock-wifi.service
sudo systemctl start rfkill-unblock-wifi.service

Hopefully this doesn't start before wifi is blocked.

source

Solution 2

In the kernel cmdline put rfkill.default_state=1. This works irrespective of the init-system and doesn't require ugly script hacks.

Solution 3

I tried mchid's answer and it didn't work for me because NetworkManager was killing the wifi after startup finished.

What did work was nmcli r wifi on

What appears to be the root of the problem is that somewhere along the line the "Enable WiFi" menu item in the GUI got unchecked.

Solution 4

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.

Long Answer:

Some specifics as to how I arrived at my conclusions in the short answer above.

1. 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.

2. 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

3. 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.

4. 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...

5. 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?!?!?

6. 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

7. 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.

8. 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.

9. 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.

10. 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...

View more solutions

Comments

[mikewhatever]

possible duplicate: askubuntu.com/questions/356622/…

[3pic]

Thank you. I have been interested in the way you way you do it, I did it in another service of mine, but this didnt work cause NetworkManager blocks it back - I dont know when -. I solved my problem with writting rfkill unblock wifi in rc.local to ensure it is unblocked at the very end of boot. It works ok. It block def' after it is blocked.

[senz]

Actually, there are already an init script for storing and restoring rfkill: /etc/init/rfkill-store.conf and /etc/init/rfkill-restore.conf

[mchid]

@senz It seems that script simply "restores" the previous state. If this ends up "restoring" to an incorrect state, you can always edit those files accordingly to explicitly unblock instead. I used to be a sysvinit guy myself but I really like the systemd ability to enable, disable, and mask services.

[tripulse]

ArchLinux forums? The forum for amateur Linux users who hold a huge ego?

[mchid]

@bsound I think you have arch confused with manjaro.

[tripulse]

@mchid Certainly not.