Le sans fil ne fonctionne pas sur un HP Pavillion DV6000 avec un Intel 3945abg
Je viens donc d'installer Ubuntu 11.10 sur mon HP Pavillion DV6000 et mon réseau sans fil ne se connecte pas. Je cherchais partout sur Internet des réponses, c’est donc mon dernier recours. Personne ne peut vraiment comprendre ce que j'ai entendu dire pour aller en ligne et faire des mises à jour parce que je n'ai pas de connexion filaire.
Il lit mon réseau sans fil et demande un mot de passe puis se connecte. Il continue à apparaître chaque minute ou à peu près, demandant le mot de passe. J'ai un contrôleur de réseau Intel Corporation PRO/Wireless 3945abg [golan].
Je suis nouveau chez Ubuntu. J'utilise un point d'accès mobile pour mon réseau sans fil. Je suis ensuite allé à modifier les connexions. J'ai trouvé mon point d'accès, puis je suis allé à la sécurité du réseau sans fil WPA & WPA2 Personal. La chose étrange est que j'ai mis à jour à partir d'ubuntu 10.10 et le sans fil a bien fonctionné sur cet ordinateur. voici mes informations.
trav@trav-HP-Pavilion-dv6000-RG360UA-ABA:~$ Sudo lshw -C network
*-network
description: Wireless interface
product: PRO/Wireless 3945ABG [Golan] Network Connection
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:02:00.0
logical name: wlan0
version: 02
serial: 00:18:de:76:19:43
width: 32 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=iwl3945 driverversion=3.0.0-14-generic firmware=15.32.2.9 latency=0 link=no multicast=yes wireless=IEEE 802.11abg
resources: irq:43 memory:d6000000-d6000fff
*-network
description: Ethernet interface
product: PRO/100 VE Network Connection
vendor: Intel Corporation
physical id: 8
bus info: pci@0000:05:08.0
logical name: eth0
version: 02
serial: 00:16:36:a3:41:98
size: 10Mbit/s
capacity: 100Mbit/s
width: 32 bits
clock: 33MHz
capabilities: pm bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e100 driverversion=3.5.24-k2-NAPI duplex=half firmware=N/A latency=64 link=no maxlatency=56 mingnt=8 multicast=yes port=MII speed=10Mbit/s
resources: irq:20 memory:d8000000-d8000fff ioport:4000(size=64)
- Informations sur le matériel: http://Pastebin.com/ENjxRd71
- Journaux: http://Pastebin.com/Y9s3UJMN
La partie intéressante de la trace est la suivante:
iwl3945 0000:0b:00.0: Card state received: HW:Kill SW:On
Comme vous l'avez également indiqué, vos résultats rfkill list all ne montrent aucun problème d'interrupteur d'arrêt du matériel/logiciel.
J'ai trouvé ce rapport très similaire .
La suggestion était de remplacer le gestionnaire de réseau par wicd (recherche dans le centre logiciel/synaptique).
Il y a un rapport de bogue pour votre carte sur le tableau de bord.
La dernière entrée dans le rapport de bogue semble prometteuse:
Créez un fichier nommé config dans /etc/pm/config.d/, en procédant comme suit:
gksudo gedit /etc/pm/config.d/config
Ajouter cette ligne:
SUSPEND_MODULES="iwl3945".
Enregistrez et redémarrez.
Ubuntu 12 corrige le problème.
*-network
description: Wireless interface
product: PRO/Wireless 3945ABG [Golan] Network Connection
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:02:00.0
logical name: wlan0
version: 02
Faites glisser le commutateur sans fil vers la droite. La lumière alterne le rouge et le bleu.
J'ai rencontré un semblable sur mon ordinateur portable et c'est arrivé chaque fois que ce n'est pas connecté au chargeur. Cela avait quelque chose à voir avec la gestion de l'alimentation wi-fi. Apparemment, j'ai dû l'éteindre de façon permanente.
ma solution pour vous ne vous embêtez pas autant d’utilisation 10.04 ou 10.10 et qu’elle reste fidèle jusqu’à ce que le prochain noyau apparaisse, c’est le problème qui concerne le noyau, c’est non seulement ubuntu qui en souffre j’ai le même problème et il m’arrive avec Fedora qui a utilisé le même noyau. Je pense qu'ils ont fait un changement tellement fou dans les pilotes en général et c'est pourquoi nous souffrons maintenant. J'ai utilisé un modem usb et ses performances sont faibles, il fonctionnait si bien avant que je suppose que ce noyau a tellement de bogues maintenant. alors n’attendez rien que nous puissions faire, à moins que quelqu'un corrige ce bogue dans le tableau de bord. C’est là que j’ai signalé moi-même et voici le lien. et son déjà confirmé https://bugs.launchpad.net/ubuntu/+bug/887317 owh alors merci de l'ajouter car cela vous affecte dans le tableau de bord
Vous pouvez rechercher dans les journaux avec quelque chose comme Sudo zegrep -n 'wpa_supplicant|NetworkManager' /var/log/* pour voir ce qui se passe.
Après avoir consulté le journal publié, voici comment je l'ai analysé.
Analyse de var_log.txt (http://Pastebin.com/Y9s3UJMN), 230 lignes comme:
/var/log/syslog:7607:Dec 18 14:57:52 trav-HP-Pavilion-dv6000-RG360UA-ABA NetworkManager[870]: <info> (wlan0): device state change: need-auth -> prepare (reason 'none') [60 40 0]
Trop d'encombrement et peut-être trop peu d'informations. Réduisons l'encombrement et voyons ce qu'il reste. L’outil que j’utilise pour cela est l’éditeur GNU Emacs, mais vous pouvez utiliser n’importe quel éditeur sur une copie du fichier, comme le faisait moi.
Toutes les lignes commencent par "/var/log/syslog:" - aucune information utile ici, supprimez-la.
Suivant est le numéro de ligne (en raison de l'option -n). Notez qu'il y a des lacunes dans la séquence des numéros de ligne. Les lignes omises (7622-7625 et autres petits espaces) sont des lignes qui ne contiennent pas "NetworkManager" ou "wpa_supplicant", mais peuvent contenir des informations intéressantes. Ceci est quelque chose pour vous de regarder. Gardons les numéros de ligne, pour le moment.
Ensuite, il y a la date, l'heure, le nom d'hôte (quel type de nom d'hôte est "trav-HP-Pavilion-dv6000-RG360UA-ABA"?? Remplacez (dans le journal) par "trav", sans perte d'information, et 31 caractères de fouillis enregistrés par ligne) et le nom du processus qui a créé l’entrée du journal. Nous avons seulement recherché "NetworkManager" ou "wpa_supplicant", donc c'est tout ce que nous avons. Notez que les PID (les ID de processus, dans []) restent les mêmes, [870] pour NetworkManager et [916] pour wpa_supplicant. Cela signifie que NetworkManager et wpa_supplicant n'ont PAS redémarré pendant ce fragment de journal. Chacun pense qu'il fonctionne "normalement".
Enfin, nous arrivons au message qui a été enregistré. NetworkManager attribue à ses messages les informations "info" ou "warn", contrairement à wpa_supplicant.
Ensuite, en regardant les messages dans le premier bloc de numéros de ligne consécutifs, 7607 à 7621:
<info> (wlan0): device state change: need-auth -> prepare (reason 'none')
<info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
<info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
<info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
<info> (wlan0): device state change: prepare -> config (reason 'none')
<info> Activation (wlan0/wireless): connection 'Auto Verizon DROIDX 19
<info> Config: added 'ssid' value 'Verizon DROIDX 1980'
<info> Config: added 'scan_ssid' value '1'
<info> Config: added 'key_mgmt' value 'WPA-PSK'
<info> Config: added 'psk' value '<omitted>'
<info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
<info> Config: set interface ap_scan to 1
<info> (wlan0): supplicant interface state: inactive -> scanning
Trying to authenticate with 40:fc:89:29:82:fb (SSID='Verizon DROIDX 19
<info> (wlan0): supplicant interface state: scanning -> authenticating
Nous voyons NetworkManager effectuer les étapes 1 et 2 (sur 5) de l'activation, puis appeler wpa_supplicant pour tenter de s'authentifier à l'aide du SSID "Verizon DROIDX 1980", adresse MAC 40: fc: 89: 29: 82: fb.
Puis, le 18 décembre à 14:58:02 et toutes les 8 secondes par la suite, les journaux du demandeur wpa:
Trying to authenticate with 40:fc:89:29:82:fb (SSID='Verizon DROIDX 1980' freq=2462 MHz)
Puis, le 18 décembre à 14:58:38, NetworkManager effectue une déconnexion à la demande de l'utilisateur.
L'examen de ces entrées de journal a été une perte de temps: vous avez recommencé à la ligne 7654 "Activation (wlan0) de la connexion" Verizon DROID2 6182 "", mais cette fois-ci, les informations sont différentes:
<info> Activation (wlan0) starting connection 'Verizon DROID2 6182'
<info> (wlan0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
<info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
<info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
<info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
<info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
<info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
<info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0]
<info> Activation (wlan0/wireless): access point 'Verizon DROID2 6182' has security, but secrets are required.
<info> (wlan0): device state change: config -> need-auth (reason 'none') [50 60 0]
<info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Puis à 14:59:27, nous voyons un autre redémarrage sans fil, toujours WPA-PSK, connu sous le nom de "secrets", mais avec la valeur 'auth_alg' ajoutée 'OPEN'. Fréquence différente.
get_secret_flags: assertion `is_secret_prop (setting, secret_name, error)' failed
<info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
<info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
<info> (wlan0): device state change: need-auth -> prepare (reason 'none') [60 40 0]
<info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
<info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
<info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
<info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0]
<info> Activation (wlan0/wireless): connection 'Verizon DROID2 6182' has security, and secrets exist. No new secrets needed.
<info> Config: added 'ssid' value 'Verizon DROID2 6182'
<info> Config: added 'scan_ssid' value '1'
<info> Config: added 'key_mgmt' value 'WPA-PSK'
<info> Config: added 'auth_alg' value 'OPEN'
<info> Config: added 'psk' value '<omitted>'
<info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
<info> Config: set interface ap_scan to 1
<info> (wlan0): supplicant interface state: disconnected -> scanning
Trying to authenticate with f8:7b:7a:4f:8f:56 (SSID='Verizon DROID2 6182' freq=2437 MHz)
Wpa_supplicant essaie un MAC et un SSID différents, puis réessaye. Le 18 décembre, 15:00:27 NetworkManager a expiré:
<warn> Activation (wlan0/wireless): association took too long.
<info> (wlan0): device state change: config -> need-auth (reason 'none') [50 60 0]
<warn> Activation (wlan0/wireless): asking for new secrets
<info> (wlan0): supplicant interface state: authenticating -> disconnected
<warn> Couldn't disconnect supplicant interface: This interface is not connected.
get_secret_flags: assertion `is_secret_prop (setting, secret_name, error)' failed
<info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
<info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
<info> (wlan0): device state change: need-auth -> prepare (reason 'none') [60 40 0]
<info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
<info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
<info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
<info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0]
<info> Activation (wlan0/wireless): connection 'Verizon DROID2 6182' has security, and secrets exist. No new secrets needed.
<info> Config: added 'ssid' value 'Verizon DROID2 6182'
<info> Config: added 'scan_ssid' value '1'
<info> Config: added 'key_mgmt' value 'WPA-PSK'
<info> Config: added 'auth_alg' value 'OPEN'
<info> Config: added 'psk' value '<omitted>'
<info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
<info> Config: set interface ap_scan to 1
<info> (wlan0): supplicant interface state: disconnected -> scanning
Trying to authenticate with f8:7b:7a:4f:8f:56 (SSID='Verizon DROID2 6182' freq=2437 MHz)
<info> (wlan0): supplicant interface state: scanning -> authenticating
puis "Essayer de s'authentifier", redémarre pour finir à 15:01:36, "demande de nouveaux secrets" et avertissement "Impossible de déconnecter l'interface du demandeur: cette interface n'est pas connectée." et "Aucun agent n'était disponible pour cette demande." qui fait allusion au (manque de) progrès de la tentative de connexion/authentification. NetworkManager abandonne 'Verizon DROID2 6182', le signalant comme invalide.
Le 18 décembre à 15:01:43, NetworkManager active automatiquement Verizon DROIDX 1980, mais la déconnexion "demandée par l'utilisateur" a lieu à 15:02:22.
À 15:02:26, NetworkManager active à nouveau automatiquement Verizon DROIDX 1980 jusqu'à 15:02:40 lorsque "la désactivation du périphérique (motif" connexion supprimée "[38]" se produit).
Les questions que j'ai à ce stade sont les suivantes:
Y a-t-il des informations intéressantes dans les lignes 7622 à 7625 et d’autres lacunes?
Pourquoi utiliser "40: fc: 89: 29: 82: fb (SSID =" Verizon DROIDX 1980 ", fréquence = 2462 MHz)" et "f8: 7b: 7a: 4f: 8f: 56 (SSID =" Verizon DROID2 6182 ". Freq = 2437 MHz) "? Lequel a raison?
Êtes-vous vraiment, vraiment, vraiment sûr d'avoir la WPA clé pré-partagée correctement entrée? S'il s'agit d'une chaîne hexagonale, essayez de remplacer [a-f] par [A-F] ou l'inverse.
Waltinator