Configuration: Ordinateur portable, carte wifi standard, Ubuntu 14.04
À chaque démarrage, Wifi/Wlan est désactivé/SoftBlocked, je peux le faire fonctionner avec la commande Sudo rfkill unblock wifi
mais après chaque redémarrage, je dois ré-émettre à nouveau cette commande (en fait, ce n'est pas tout à fait vrai, parfois (5%), elle semble "s'en tenir" lors d'un redémarrage).
Existe-t-il un moyen de dire à rfkill de ne jamais bloquer le wifi, sans avoir à le dire aussi explicitement à chaque fois?
Vous pouvez faire un service pour le faire. Exécutez la commande suivante:
Sudo nano /etc/systemd/system/rfkill-unblock-wifi.service
puis copiez et collez le texte suivant dans le fichier:
[Unit]
Description=RFKill-Unblock WiFi Devices
[Service]
Type=oneshot
ExecStart=/usr/sbin/rfkill unblock wifi
ExecStop=
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
Presse CTRL + o puis appuyez sur ENTER pour sauvegarder le fichier. presse CTRL + x sortir nano.
Enfin, exécutez la commande suivante pour activer le démarrage du service:
Sudo systemctl enable rfkill-unblock-wifi.service
Sudo systemctl start rfkill-unblock-wifi.service
Espérons que cela ne commence pas avant que le wifi ne soit bloqué.
J'ai rencontré ce cauchemar en configurant un Dell Edge GW en tant qu'AP, à l'aide du package hostapd . Lors de la recherche sur Google, j'ai vu beaucoup de gens se plaindre de blocages lors de la configuration d'un point d'accès dans différents forums. Diverses hacks ont été proposés comme solutions de rechange, mais aucun des messages n'a vraiment identifié la cause première des blocs modérés. Après de longues analyses, j'ai découvert à quel point c'était cassant.
Bien que certaines parties de la réponse ci-dessous soient spécifiques à Dell Edge / hostapd config, ça vaut toujours la peine de le lire car cela donne un bon aperçu de la manière dont un bloc souple est lancé.
c'est-à-dire que NetworkManager utilise la radio car il contrôle le GSM wwan0 interface. Mais lorsque , hostapd essaie d'accéder à la radio par le biais de wlan0 SI qui est PAS géré par NetworkManager car ils ne jouent pas bien entre eux - ils entrent en conflit . NetworkManager convoite gaiement la radio et si quoi que ce soit d'autre tente de l'utiliser, NetworkManager (-) jette malicieusement un bloc
Bien que la solution puisse sembler évidente - gérer l’accès radio dans un système de gestion d’interface de manière uniforme - ce n’est pas si simple:
Lorsque vous utilisez hostapd pour votre point d'accès, le réseau WiFi si (généralement wlan0 ) doit être levé à l'aide de ip
commandes AFTER et NM terminé (et assurez-vous que rien d'autre ne redémarre NM). J'ai trouvé faire un rfkill unblock all
avant et après avoir soulevé le wlan0 SI avec des commandes IP effacées effacé le bloc logiciel permettant au wlan0 IF de démarrer correctement quel jour est autorisé hostapd pour démarrer normalement au redémarrage.
Quelques détails sur la façon dont je suis arrivé à mes conclusions dans la réponse courte ci-dessus.
Gestion IF : pour leur passerelle Edge, Dell a activé dans leur image 18.04 BOTH systemd-networkd ET NetworkManager , mais dans , Netplan a remplacé la gestion des IF par la suite. Vous remarquerez qu'une installation standard 18.04 n'a que systemd-networkd comme configuration par défaut pour la gestion IF.
Le wrapper permettant de configurer un AP avec hostapd " create_AP ", raccroche l'interface WiFi de NM contrôle et utilise les commandes ip link set
pour augmenter le WiFi IF (ligne 1697 dans le lien ci-dessus). Bien que "_create_ap)" fasse partie de l'image 16.04 de Dell, il n'est plus présent dans l'image 18.04, ce qui permet à l'utilisateur de configurer manuellement le point d'accès. C'est ici que commence le plaisir
Après avoir configuré l’interface GSM wwan0 avec succès à l’intérieur de NM, j'ai configuré le réseau WiFi wlan0 dans NM également. Cela échoua pour les mêmes raisons " create_ap " et Arch Linux le décrocha, comme je le trouvai plus tard dans le prev liens référencés pour NM. Ainsi, conformément aux instructions Arch Linux, j’ai ajouté la directive unmanaged-devices=mac:<hwaddr>
pour le wlan0 dans /etc/NetworkManager/NetworkManager.conf
pour s’assurer que NM n’a pas causé d’autres ravages.
Réaliser NM n'était pas un élément de démarrage pour la configuration hostapd , j'ai ensuite configuré le wlan0 SI être géré par systemd-networkd . Cependant, l’erreur suivante a révélé que cela ne fonctionnerait pas avec hostapd soit: ERREUR: wlan0: networkd ne prend pas en charge le wifi en mode point d'accès . Je perdais rapidement l'envie de vivre. Si je n'avais pas rendu mon Glock quand j'ai quitté NYPD, je me serais probablement fait mal à moi-même ...
Ni NM ou systemd-networkd étant une option permettant de gérer le wlan0 interface, il ne me restait plus qu'à le configurer ip
commandes. Et cela a fonctionné- MANUELLEMENT. Cependant, au redémarrage, le bloc logiciel a été lancé, malgré le décrochage wlan0 de NM. Donc si NM ne lance pas les blocs souples maintenant, qu'est-ce que c'est?!?!?
Une analyse plus poussée a révélé que NM était toujours en jeu. J'ai trouvé dhcpcd.service avait un NM raccroché au démarrage, le redémarrage du client dhcpcd aurait alors NM élever sa tête laide. ps aux
a révélé ce qui se passait: /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /run/dhclient-eth0.pid
J'ai découvert que tout ce qui causait NM au démarrage entraînerait le blocage du bloc logiciel jeté. Donc, dans mes scripts, j'ai supprimé tout ce qui demandait à NM de redémarrer ou tout ce qui demandait dhcpcd.service à redémarrer. Mais le problème reste ENCORE PERSISTE .
Bien que le relèvement manuel du wlan0 SI ait réussi à autoriser hostapd pour monter correctement, un redémarrage a provoqué le blocage logiciel qui va arrêter le wlan0 IF à partir du moment où il est effacé.
Donc, la seule solution à laquelle j'ai pu arriver était de relever le wlan0 SI APRÈS NM est terminé et garantit qu'aucun autre élément n'a été redémarré NM une fois wlan0 était en place. Dans mes scripts, j'ai ajouté un rfkill unblock all
à la fois avant et après le début du wlan0
IF à l'aide de ip
commandes. CECI A FINALEMENT TRAVAILLÉ .
Vous pourriez penser: " Terrence, pourquoi ne pas essayer de modérer le comportement de dhcpcd.service dans son fichier unité plutôt que de le pirater dans des scripts! "Préférant des solutions élégantes aux hacks, j’ai examiné ceci: il n’est pas possible de modifier de manière persistante que dhcpcd.service car le fichier est généré dynamiquement et ne persiste pas après les redémarrages !! Exécutez find / -name dhcpcd.service
et vous verrez que les fichiers d’unités décrivant ce service existent dans/exécuter. Crack one open et on vous dira: # Généré automatiquement par systemd-sysv-generator
Commandes que j'ai écrites pour arrêter NM de monopoliser la radio:
sed -i "/managed=true/a unmanaged-devices=interface-name:$INTERFACEAP" /etc/NetworkManager/NetworkManager.conf
nmcli radio wifi off
Commandes que j'ai écrites pour élever le wlan0 SI utilisant des commandes IP, indépendant des deux NM et systemd-networkd :
rfkill unblock all
ip addr add $IPV4IPWLAN0 dev $INTERFACEAP
ip link set $INTERFACEAP up
rfkill unblock all
Bien que j'ai hostapd enfin actif, je vais en thérapie 7 jours sur 7 et mon thérapeute dit que je progresse bien pour surmonter cette expérience. Anyhoo, espérons que j'ai sauvé les autres de cet enfer vivant ...
J'ai essayé la réponse de mchid et cela n'a pas fonctionné pour moi car NetworkManager détruisait le wifi après le démarrage est terminé.
Qu'est-ce que le travail était nmcli r wifi on
Ce qui semble être à l'origine du problème est que, quelque part sur la ligne, l'élément de menu "Activer le WiFi" de l'interface graphique n'a pas été coché.