Outils personnels
Vous êtes ici : Accueil Linux Linux - Bon à savoir (ou FAQ) Plus de connexion Wi-Fi !? (ou comment sortir d'un Wireless LAN: hard blocked)
Se connecter


Mot de passe oublié ?
 

Plus de connexion Wi-Fi !? (ou comment sortir d'un Wireless LAN: hard blocked)

Par Freecrazy - Dernière modification 23/10/2016 08:07

Sur certains ordinateurs portables (HP, Asus, ...) des mises à jour nous 'casse' le wifi. Une commande rfkill list nous renvoie un 'Wireless hard blocked' et actionner le switch matériel du Wi-Fi n'y change rien. Après le parcours d'une multitude de threads, j'ai enfin trouvé 'LA' solution, au moins pour mon PC. C'est pourquoi ici, je vais être plus prolixe sur mes recherches et donner un maximum de liens afin que chacun, j'espère, puisse trouver la solution adaptée à son micro.

La première fois que j'ai rencontré ce problème c'était fin 2015 suite à une mise à jour de ma Debian sur un portable HP Compaq 6710b. La seconde fois c'était aujourd'hui lorsque j'ai voulu refaire une installation complète sur ce même micro.

Contrairement à d'habitude, je vais détailler mes recherches en espérant que chacun puisse y puiser l'inspiration pour trouver la solution à son problème.

Les plus pressés pourront aller directement à la solution (paragraphe '3 - LA solution') qui fonctionne pour mon micro portable.

1 - Le Wi-Fi ne fontionne plus, nous sommes un 29/12/2015 !

Hier j'ai fait une mise à jour, et aujourd'hui bizarrement mon wifi est tombé en rade.

Au début je pensais que c'était, comme d'habitude, dû à mon switch tactile, mais à priori non (enfin pas seulement) !
Ma fenêtre wicd ne trouvait pas d'interface wireless (Aucun réseau sans fil détecté) et donc ne pouvait pas faire de recherche (scan réseau).
Après des iwconfig, ifconfig wlan0 up, ... J'ai mis un (certain) temps avant de trouver la solution:

root> ifconfig wlan0 up
SIOCSIFFLAGS: Opération impossible du fait de RF-kill
root> rfkill list
0: phy0: Wireless LAN
	Soft blocked: yes
	Hard blocked: yes
1: hp-wifi: Wireless LAN
	Soft blocked: yes
	Hard blocked: yes
2: hp-bluetooth: Bluetooth
	Soft blocked: yes
	Hard blocked: yes
3: hp-gps: GPS
	Soft blocked: yes
	Hard blocked: yes

Bon je ne savais pas que j'avais autant de possibilités sans fil (surtout le GPS qui me laisse sceptique), mais cela a le mérite de m'indiquer qu'il y a au minimum un blocage hard ! Donc j'effleure mon switch tactile et cette fois j'obtiens:

root> rfkill list
0: phy0: Wireless LAN
	Soft blocked: yes
	Hard blocked: yes
1: hp-wifi: Wireless LAN
	Soft blocked: yes
	Hard blocked: no
2: hp-bluetooth: Bluetooth
	Soft blocked: yes
	Hard blocked: no
3: hp-gps: GPS
	Soft blocked: yes
	Hard blocked: yes

Donc à priori le GPS s'il peut s'activer ce n'est pas grâce à ce switch alors que c'est le cas pour le Bluetooth ...

Mais ma priorité pour l'instant c'est le wifi: donc mon switch tactile est bien positionné mais j'ai toujours un Soft blocked. Par ailleurs la ligne '0: phy0: Wireless LAN' reste un mystère pour moi.

Mais débloquons le Soft blocked avec:

root> rfkill unblock wifi
root> rfkill list
0: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: yes
1: hp-wifi: Wireless LAN
	Soft blocked: no
	Hard blocked: no

Cela semble bon là, ... mais non car:

root> ifconfig wlan0 up
SIOCSIFFLAGS: Opération impossible du fait de RF-kill

Un moment de réflexion, un peu (beaucoup) de lecture de threads et je me dis que la liaison filaire en place doit gêner. Je l'enlève et là ... cela fonctionne.
Ce dernier point me fait penser que je ne peux pas lancer 1 connexion filaire et une connexion wifi en même temps (ceci étant cela ne me surprend pas outre-mesure puisque wicd ne sait gérer qu'une carte wifi à la fois) mais au vu de ce post il y a peut-être à regarder le paramétrage du Bios (une option switch wan/lan mal positionnée).

Sinon:

  • Avec une recherche "linux wifi non connecté wicd" on tombe sur ce lien [wicd] Impossible de se connecter à un réseau (résolu) - Archlinux et on apprend que "L’utilitaire hostname a été déplacé du paquet net-tools vers inetutils." J'ai failli installer inetutils-tools avant de me rendre compte que Debian a géré ce changement différemment de Archlinux comme on peut le voir dans la description de net-tools, je cite "... Dans le paquet d'origine, les utilitaires hostname et autres sont inclus. Ceux-ci ne sont pas installés par ce paquet, puisqu'ils font partie d'un paquet spécifique « hostname*.deb".
  • Dans ce post (En) on trouve une résolution similaire sur un HP également.
  • J'ai redécouvert quelques commandes: lshw -C network, aptitude show firmware-realtek, iwlist scan et remémorer les fichiers: /etc/network/interfaces (mais qui ne contient plus que lo), /etc/wicd/wireless-settings.conf (mais qui n'est que l'historique de toutes mes connexions) et enfin /var/log/wicd/wicd.log

Problème résolu ? Je le croyais et j'étais content donc vous imaginez ma déception lorsque le lendemain après redémarrage de mon PC  je me retrouve de nouveau en rade: phy0 est hard blocked alors que je n'ai pas de câble de branché ??, il va falloir que je creuse.

2 - Analyse du problème

Précédemment j'avais réussi à redémarrer ma connexion wifi bloquée par rfkill mais je n'avais pas réussi à rendre cette configuration persistante. J'ai donc opté pour une démarche plus rationnelle en commençant par la :

2.1 -  Recherche d'erreurs éventuelles lors du boot

Attention lisez la suite comme une méthodologie: vous arriverez certainement à lancer les commandes indiquées car elles sont, autant que je le sache, toujours présentes dans un système Linux même basique. Par contre les sorties ne sont données qu'à titre purement indicatif et ne valent que pour la configuration testée (matérielle et logicielle), vous aurez inévitablement des messages différents. 

root> dmesg -H | grep wifi
[  +0,541106] iwl3945 0000:10:00.0: firmware: direct-loading firmware iwlwifi-3945-2.ucode

Bon à priori rien d'anormal de ce côté là. Essayons de voir s'il y a des erreurs:

root> dmesg -Hl err
[janv. 2 08:54] CIFS VFS: Error connecting to socket. Aborting operation.
[  +0,000226] CIFS VFS: cifs_mount failed w/return code = -101
[  +0,003543] CIFS VFS: Error connecting to socket. Aborting operation.
[  +0,000325] CIFS VFS: cifs_mount failed w/return code = -101
[  +0,004007] CIFS VFS: Error connecting to socket. Aborting operation.
[  +0,000305] CIFS VFS: cifs_mount failed w/return code = -101
[  +0,003187] CIFS VFS: Error connecting to socket. Aborting operation.
[  +0,000353] CIFS VFS: cifs_mount failed w/return code = -101

Rien d'anormal non plus, puisque seuls les montages à mon serveur apparaissent en erreur ce qui est logique puisque la connexion ne fonctionne pas ! Voyons voir les warnings:

root> dmesg -Hl warn
[janv. 2 08:53] ACPI: RSDP 0x00000000000F7150 000024 (v02 HP    )
[  +0,000000] ACPI: XSDT 0x000000007F7C81CC 000084 (v01 HPQOEM SLIC-MPC 00000001 HP   00000001)
[  +0,000000] ACPI: FACP 0x000000007F7C8084 0000F4 (v04 HP     30C0     00000003 HP   00000001)
[  +0,000000] ACPI: DSDT 0x000000007F7C84D8 01313E (v01 HP     nc75xx   00010000 MSFT 03000001)
[  +0,000000] ACPI: FACS 0x000000007F7E7D80 000040
[  +0,000000] ACPI: FACS 0x000000007F7E7D80 000040
[  +0,000000] ACPI: SLIC 0x000000007F7C8250 000176 (v01 HPQOEM SLIC-MPC 00000001 HP   00000001)
[  +0,000000] ACPI: HPET 0x000000007F7C83C8 000038 (v01 HP     30C0     00000001 HP   00000001)
[  +0,000000] ACPI: APIC 0x000000007F7C8400 000068 (v01 HP     30C0     00000001 HP   00000001)
[  +0,000000] ACPI: MCFG 0x000000007F7C8468 00003C (v01 HP     30C0     00000001 HP   00000001)
[  +0,000000] ACPI: TCPA 0x000000007F7C84A4 000032 (v02 HP     30C0     00000001 HP   00000001)
[  +0,000000] ACPI: SSDT 0x000000007F7DB616 000059 (v01 HP     HPQNLP   00000001 MSFT 03000001)
[  +0,000000] ACPI: SSDT 0x000000007F7DB66F 000328 (v01 HP     HPQSAT   00000001 MSFT 03000001)
[  +0,000000] ACPI: SSDT 0x000000007F7DB997 00017D (v01 HP     HPQMRM   00000001 MSFT 03000001)
[  +0,000000] ACPI: SSDT 0x000000007F7DC4DA 00025F (v01 HP     Cpu0Tst  00003000 INTL 20060317)
[  +0,000000] ACPI: SSDT 0x000000007F7DC739 0000A6 (v01 HP     Cpu1Tst  00003000 INTL 20060317)
[  +0,000000] ACPI: SSDT 0x000000007F7DC7DF 0004D7 (v01 HP     CpuPm    00003000 INTL 20060317)
[  +0,000000] Zone ranges:
[  +0,000000]   DMA      [mem 0x00001000-0x00ffffff]
[  +0,000000]   DMA32    [mem 0x01000000-0xffffffff]
[  +0,000000]   Normal   empty
[  +0,000000] Movable zone start for each node
[  +0,000000] Early memory node ranges
[  +0,000000]   node   0: [mem 0x00001000-0x0009efff]
[  +0,000000]   node   0: [mem 0x00100000-0x7f7affff]
[  +0,000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 514902
[  +0,000000] Policy zone: DMA32
[  +0,000000] Memory: 2032196K/2088248K available (5219K kernel code, 947K rwdata, 1836K rodata,
                      1204K init, 840K bss, 56052K reserved)
[  +0,000000] ACPI: All ACPI Tables successfully acquired
[  +0,056909] perf_event_intel: PEBS disabled due to CPU errata
[  +0,017993] mtrr: your CPUs had inconsistent variable MTRR settings
[  +0,084712] ACPI: Dynamic OEM Table Load:
[  +0,000010] ACPI: SSDT 0xFFFF88007C220C00 00027F (v01 HP     Cpu0Ist  00003000 INTL 20060317)
[  +0,000555] ACPI: Dynamic OEM Table Load:
[  +0,000008] ACPI: SSDT 0xFFFF88007C1CD000 0005FA (v01 HP     Cpu0Cst  00003001 INTL 20060317)
[  +0,000605] ACPI: Dynamic OEM Table Load:
[  +0,000007] ACPI: SSDT 0xFFFF88007C1A0200 0000C8 (v01 HP     Cpu1Ist  00003000 INTL 20060317)
[  +0,000494] ACPI: Dynamic OEM Table Load:
[  +0,000006] ACPI: SSDT 0xFFFF88007C1BC880 000085 (v01 HP     Cpu1Cst  00003000 INTL 20060317)
[  +0,031680] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20140424/hwxface-580)
[  +0,000006] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20140424/hwxface-580)
[  +0,044871] pci 0000:00:1e.0: bridge has subordinate 03 but max busn 06
[  +0,002132] ACPI Exception: AE_NOT_FOUND, Evaluating _PRS (20140424/pci_link-178)
[  +0,000987] ACPI: Enabled 8 GPEs in block 00 to 1F
[  +0,006355] Expanded resource reserved due to conflict with PCI Bus 0000:00
[  +0,021952] pci 0000:00:1f.0: BAR 13: [io  0x1000-0x107f] has bogus alignment
[  +0,397715] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[  +0,726059] sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
[  +1,035611] systemd[1]: Cannot add dependency job for unit display-manager.service,
              ignoring: Unit display-manager.service failed to load: No such file or directory.
[  +0,764975]  excluding 0xe4200000-0xe423ffff
[  +0,601443]  excluding 0xc0000-0xd3fff 0xe0000-0xfffff
[  +0,000027]  clean.
[  +0,000025]  excluding 0x60000000-0x60ffffff
[  +0,850069] ACPI Exception: AE_AML_PACKAGE_LIMIT, Index (0x000000004) is beyond end of object
              (length 0x4) (20140424/exoparg2-420)
[  +0,000030] ACPI Error: Method parse/execution failed [\_SB_.C003.C098._DOD] (Node ffff88007c841d88),
              AE_AML_PACKAGE_LIMIT (20140424/psparse-536)
[  +0,000027] ACPI Exception: AE_AML_PACKAGE_LIMIT, Evaluating _DOD (20140424/video-1431)
[  +1,651809] ACPI Warning: SystemIO range 0x0000000000001028-0x000000000000102F conflicts with OpRegion
              0x0000000000001000-0x0000000000001042 (\_SB_.C003.C004.C0D2) (20140424/utaddress-254)
[  +0,000013] ACPI Warning: SystemIO range 0x0000000000001130-0x000000000000113F conflicts with OpRegion
              0x0000000000001100-0x000000000000113B (\_SB_.C003.C004.C0E4) (20140424/utaddress-254)
[  +0,000007] ACPI Warning: SystemIO range 0x0000000000001100-0x000000000000112F conflicts with OpRegion
              0x0000000000001100-0x000000000000113B (\_SB_.C003.C004.C0E4) (20140424/utaddress-254)
[  +0,000006] lpc_ich: Resource conflict(s) found affecting gpio_ich
[  +0,128068] iwl3945 0000:10:00.0: can't disable ASPM; OS doesn't have ASPM control
[janv. 2 09:10] perf interrupt took too long (2509 > 2500), lowering kernel.perf_event_max_sample_rate
                to 50000
 Là c'est beaucoup plus long, mais l'avant dernière ligne interpelle (celle mise en gras).

2.2 -  Recherche Google avec cette ligne de warning

Il y a des résultats dont:

  • le premier, un 'bug report' de nov 2013 mais qui vaut pour Redhat et franchement n'apporte rien
  • le second est relatif à Ubuntu et date de février 2014. Ce post est intéressant car l'initiateur du post indique la sortie de wireless-script (à priori script disponible sous Ubuntu) qui effectue plusieurs commandes permettant d'obtenir toutes les infos utiles pour cerner un problème wifi. Mais au-delà de ces commandes qu'il est toujours intéressant de connaître, il donne une solution potentielle.
 

La solution proposée est de faire un reset du BIOS (c.a.d revenir à la configuration d'origine/usine).

Je n'y croyais pas de trop mais ma configuration du BIOS n'est pas compliquée  (car souvent on n'y touche guère), je saurai donc y revenir facilement, donc j'essaie. Et effectivement au redémarrage phy0 n'est plus 'Hard blocked':

root> rfkill list
0: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
2: hp-wifi: Wireless LAN
	Soft blocked: yes
	Hard blocked: no

Cependant ma connexion wifi ne se fait toujours pas puisque hp-wifi est 'Soft blocked' !!!

A la lecture d'autres threads on peut penser que la solution est toujours dans le BIOS. Il y a en effet une option qui chez moi s'appelle 'Permutation LAN/WLAN (réseau sans fil)' qui est désactivée par défaut, je n'ai jamais su à quoi elle sert mais elle doit ici jouer un rôle, donc remodif du BIOS .. et cette fois phy0 est de nouveau 'Hard blocked' ... Donc la solution n'est pas (que) dans le BIOS !!!

Cela commence à m'énerver ! 

2.3 - Recherche Google avec 'how to start with rfkill unblock all'

J'ai lu quelques threads et tous donnaient cette solution de contournement: ajouter la commande de déblocage dans /etc/rc.local, comme ceci:

root> nano /etc/rc.local
rfkill unblock all  <--- ligne à ajouter avant
exit 0              <--- celle-ci

 Cette solution fonctionne !. Mais je n'en suis satisfait qu'à moitié car cela reste du contournement.

Nota:

  • Pour que cela marche il faut débloquer le wifi avant de rebooter avec rfkill unblock all
  • J'ai essayé un moment 'unblock wifi' au lieu de 'unblock all', mais cela n'a pas fonctionné longtemps.
  • De même pour un bon fonctionnement il faut à priori activer dans le BIOS 'Permutation LAN/WLAN (réseau sans fil)' qui est désactivé par défaut comme on l'a vu.

Ca y est, vous pensez que je m'en suis sorti ? Et bien non, cette solution ne fonctionne pas toujours ! 

Hier j'ai fait tous mes essais avec des redémarrages successifs et cette solution fonctionnait, mais là après un arrêt 'normal'  cela ne marche pas ! (il faudrait voir précisément les différences entre 'arrêt - démarrage' et 'redémarrage' car là aussi systemd a introduit des changements). Je ne sais que penser !

2.4 - Et si je modifiais le comportement du module rfkill ?

La commande 'modinfo rfkill' retourne:

filename:       /lib/modules/3.16.0-4-amd64/kernel/net/rfkill/rfkill.ko
license:        GPL
description:    RF switch support
author:         Johannes Berg <johannes@sipsolutions.net>
author:         Ivo van Doorn <IvDoorn@gmail.com>
depends:        
intree:         Y
vermagic:       3.16.0-4-amd64 SMP mod_unload modversions 
parm:           master_switch_mode:SW_RFKILL_ALL ON should: 0=do nothing (only unlock); 1=restore;
                                                            2=unblock all (uint)
parm:           default_state:Default initial state for all radio types, 0 = radio off (uint)

On voit à la dernière ligne que par défaut rfkill est en radio.off, et l'avant dernière ligne semblerait pouvoir mettre le module en 'unblock all'. Donc j'ai essayé ceci (source):

root> nano /etc/modprobe.d/option    ← fichier que j'ai créé
options rfkill default_state=1
options rfkill master_switch_mode=2

Mais cela n'a pas eu l'effet escompté.

J'ai aussi essayé de passer la commande 'modprobe rfkill default_state=1,master_switch_mode=2' mais cela ne change rien.

Enfin suivant ce post, j'ai créé un fichier /etc/modprobe.d/rfkill.conf avec 'options rfkill default_state=1,master_switch_mode=2', puis j'ai lancé une mise à jour de l'initramfs avec la commande 'update-initramfs -u', mais là au redémarrage rfkill n'était plus accessible et comme toujours je n'avais pas de wifi !

Là j'en ai marre de chercher, je reviens à ma solution du point 2.3.

3 - LA solution

J'avais abandonné quand en refermant tous les threads que j'avais ouverts je suis tombé sur celui-ci du site archlinux (trouvé avec une recherche Google 'pourquoi rfkill block||bloque phy0 démarrage||start') qui donne une autre solution: blacklister hp_wmi. On procède comme ceci:

root> echo "blacklist hp_wmi" > /etc/modprobe.d/hp.conf

avant de rebooter débloquer le wifi avec:

root> rfkill unblock all

au premier démarrage, le reset du BIOS peut être nécessaire donc faites le. Et tout fonctionne parfaitement: la led bleue (wifi en fonctionnement) est constamment allumée y/c lors du boot, un appui dessus coupe le wifi (et la led bleu s'éteint), une connexion filaire est reconnue, un retour au wifi aussi. Et ce bon fonctionnement perdure !

Nota:

  • Un "blacklist wmi" suffit, mais j'aime bien être précis (Ainsi pour une autre marque je mettrai <marque>_wmi, mais vous faites comme vous voulez)
  • Comme indiqué, le reset du BIOS est peut-être nécessaire, mais seulement au premier démarrage (en fait cela vous permet d'être sûr que votre switch est positionné à 'on', car dans le cas d'un switch tactile comme pour mon HP on ne sait pas dans quel état il est !) 
 

4 - Quelques infos supplémentaires

4.1 Origine du problème

Je me suis demandé pourquoi c'est arrivé, j'ai donc cherché dans les log de mises à jour (à ce stade ce lien sur la gestion des paquets Debian est une référence):

root> cat /var/log/dpkg.log.1 | grep 2015-12-29
2015-12-29 14:40:20 startup archives unpack
2015-12-29 14:40:22 upgrade wicd:all 1.7.2.4-4.1 1.7.2.4-4.1
2015-12-29 14:40:22 status half-configured wicd:all 1.7.2.4-4.1
2015-12-29 14:40:22 status unpacked wicd:all 1.7.2.4-4.1
2015-12-29 14:40:22 status half-installed wicd:all 1.7.2.4-4.1
2015-12-29 14:40:22 status half-installed wicd:all 1.7.2.4-4.1
2015-12-29 14:40:22 status unpacked wicd:all 1.7.2.4-4.1
2015-12-29 14:40:22 status unpacked wicd:all 1.7.2.4-4.1
2015-12-29 14:40:22 startup packages configure
2015-12-29 14:40:22 configure wicd:all 1.7.2.4-4.1 <aucune>
2015-12-29 14:40:22 status unpacked wicd:all 1.7.2.4-4.1
2015-12-29 14:40:22 status half-configured wicd:all 1.7.2.4-4.1
2015-12-29 14:40:22 status installed wicd:all 1.7.2.4-4.1
2015-12-29 14:40:23 startup packages configure

Il y a eu une mise à jour le 28/12/2015 avec une mise à jour de grub2, il me semble cependant que mes problèmes datent de cette mise à jour du 29. Et là on voit que c'est wicd qui a été mis à jour. Mais j'ai eu beau regarder ce qui avait changé (en lisant le README et le NEWS - pour le chemin lancer la commande 'root> dpkg -L wicd') je n'ai rien trouvé qui puisse engendrer ce problème !

Si quelqu'un a une idée, je suis preneur !

4.2 Un rapport avec Systemd ?

J'ai essayé de comprendre les modifications apportées par Systemd, mais bon cela fait pas mal de la lecture ...

Il y a cet article sur Systemd sur le site d'ArchLinux, très intéressant notamment sur l'utilisation de systemctl et journalctl.

Mais on a aussi des pages chez Debian comme celle-ci ou celle-là plus relative à l'installation et enfin je viens de trouver la page Debian sur Systemd en français.

Après cela vous saurez tout :-)) ... Oui je sais cela ne veut rien dire ...

 

Actions sur le document