☰

Wireless funktioniert nicht auf einem HP Pavillion DV6000 mit einem Intel 3945abg

tag-icon • tag-icon 11.10 wireless intel-wireless hp-pavilion
Wireless funktioniert nicht auf einem HP Pavillion DV6000 mit einem Intel 3945abg

Ich habe gerade Ubuntu 11.10 auf meinem HP Pavillion DV6000 installiert und meine WLAN-Verbindung funktioniert nicht. Ich habe das ganze Internet nach Antworten durchsucht, also ist dies mein letzter Ausweg. Niemand kann es richtig herausfinden. Ich habe gehört, ich soll online gehen und Updates durchführen, da ich keine Kabelverbindung habe.

Es liest mein WLAN und fragt nach dem Passwort, kann dann aber einfach keine Verbindung herstellen. Es erscheint etwa jede Minute und fragt nach dem Passwort. Ich habe einen Intel Corporation PRO/Wireless 3945abg [golan] Netzwerkcontroller.

Ich bin neu bei Ubuntu. Ich verwende einen mobilen Hotspot für mein WLAN. Dann habe ich Verbindungen bearbeitet, meinen Hotspot gefunden und bin dann zur WLAN-Sicherheit gegangen. Es ist WPA & WPA2 Personal. Ich habe sichergestellt, dass die Passphrase richtig ist. Das Merkwürdige ist, dass ich von Ubuntu 10.10 aktualisiert habe und das WLAN auf diesem Computer einwandfrei funktioniert hat. Hier sind meine Informationen.

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)

Antwort1

Der interessante Teil der Ablaufverfolgung ist dieser:

iwl3945 0000:0b:00.0: Card state received: HW:Kill SW:On

Wie Sie auch angegeben haben, zeigen Ihre rfkill list allErgebnisse keine Hardware-/Software-Killswitch-Probleme.

ich fanddieser sehr ähnliche Bericht.

Der Vorschlag war, den Netzwerk-Manager durch wicd zu ersetzen (Suche im Software Center/Synaptic).

Da ist einFehlerberichtfür Ihre Karte auf dem Launchpad.

Der letzte Eintrag im Fehlerbericht sieht vielversprechend aus:

Erstellen Sie eine Datei mit dem Namen configin /etc/pm/config.d/, indem Sie wie folgt vorgehen:

gksudo gedit /etc/pm/config.d/config

Fügen Sie diese Zeile hinzu:

SUSPEND_MODULES="iwl3945".

Speichern und neu starten.

Antwort2

Ubuntu 12 behebt das Problem.

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

Schieben Sie den Wireless-Schalter nach rechts. Das Licht wechselt zwischen rot und blau.

Antwort3

Sie könnten die Protokolle mit etwas wie durchsuchen, sudo zegrep -n 'wpa_supplicant|NetworkManager' /var/log/*um zu sehen, was los ist.

Nachdem ich mir das veröffentlichte Protokoll angesehen habe, kann ich es wie folgt analysieren.

Analyse von var_log.txt ( http://pastebin.com/Y9s3UJMN), 230 Zeilen wie:

/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]

Zu viel Durcheinander und möglicherweise zu wenig Informationen. Lassen Sie uns das Durcheinander reduzieren und sehen, was übrig bleibt. Das Tool, das ich hierfür verwende, ist der GNU Emacs-Editor, aber Sie können, so wie ich, jeden beliebigen Editor für eine Kopie der Datei verwenden.

Alle Zeilen beginnen mit „ /var/log/syslog:“ – hier sind keine nützlichen Informationen enthalten, bitte löschen.

Als nächstes folgt die Zeilennummer (aufgrund der Option -n). Beachten Sie, dass es Lücken in der Zeilennummernfolge gibt. Die ausgelassenen Zeilen (7622-7625 und andere kurze Lücken) sind Zeilen, die weder " NetworkManager" noch " wpa_supplicant" enthalten, aber interessante Informationen enthalten könnten. Das sollten Sie sich einmal ansehen. Lassen wir die Zeilennummern vorerst unverändert.

Dann gibt es Datum, Uhrzeit, Hostname (was für ein Hostname ist " trav-HP-Pavilion-dv6000-RG360UA-ABA"? Ersetzen Sie es (im Protokoll) durch " trav", ohne dass Informationen verloren gehen und 31 Zeichen an Datenmüll pro Zeile gespart werden) und den Prozessnamen, der den Protokolleintrag erstellt hat. Wir haben nur nach " NetworkManager" oder " " gesucht, das ist also alles, was wir haben. Beachten Sie, dass die PIDs (die Prozess-IDs in []) für und für wpa_supplicantgleich bleiben . Dies bedeutet, dass NetworkManager und wpa_supplicant während dieses Protokollfragments NICHT neu gestartet wurden. Sie denken beide, dass sie „normal“ funktionieren.[870]NetworkManager[916]wpa_supplicant

Schließlich kommen wir zu der Nachricht, die protokolliert wurde. NetworkManager kennzeichnet seine Nachrichten mit „info“ oder „warn“, wpa_supplicant tut dies nicht.

Betrachten wir dann die Nachrichten im ersten Block mit den aufeinanderfolgenden Zeilennummern 7607 bis 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

Wir sehen, dass NetworkManager Phase 1 und Phase 2 (von 5) der Aktivierung durchführt und dann wpa_supplicant aufruft, um zu versuchen, sich mit der SSID „Verizon DROIDX 1980“, MAC-Adresse 40:fc:89:29:82:fb, zu authentifizieren.

Dann, am 18. Dezember um 14:58:02 und danach alle 8 Sekunden, protokolliert wpa-supplicant:

Trying to authenticate with 40:fc:89:29:82:fb (SSID='Verizon DROIDX 1980' freq=2462 MHz)

Dann, am 18. Dezember um 14:58:38, führt NetworkManager eine vom Benutzer angeforderte Trennung durch.

Das Durchsehen dieser Protokolleinträge war Zeitverschwendung. Ich habe noch einmal bei Zeile 7654 „Aktivierung (wlan0) startet Verbindung ‚Verizon DROID2 6182‘“ angefangen, aber dieses Mal gibt es einige andere Informationen:

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

Dann sehen wir um 14:59:27 einen weiteren Neustart des WLANs, immer noch WPA-PSK, bekannte „Geheimnisse“, aber mit hinzugefügtem „auth_alg“-Wert „OPEN“. Andere Frequenz.

 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)

Am Ende probiert wpa_supplicant eine andere MAC-Adresse und SSID aus und versucht es erneut. Am 18. Dezember um 15:00:27 ist bei NetworkManager eine Zeitüberschreitung aufgetreten:

 <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

dann mehr „Versuch zur Authentifizierung“, Neustarts, endet bei 15:01:36, „Neue Geheimnisse werden angefordert“ und die Warnung „Supplicant-Schnittstelle konnte nicht getrennt werden: Diese Schnittstelle ist nicht verbunden.“ und „Für diese Anfrage waren keine Agenten verfügbar“, was auf den (fehlenden) Fortschritt des Verbindungs-/Authentifizierungsversuchs hinweist. NetworkManager gibt „Verizon DROID2 6182“ auf und markiert es als ungültig.

Am 18. Dezember um 15:01:43 Uhr aktiviert NetworkManager automatisch Verizon DROIDX 1980, die Verbindung wird jedoch um 15:02:22 Uhr aufgrund einer vom Benutzer angeforderten Trennung unterbrochen.

Um 15:02:26 Uhr aktiviert NetworkManager Verizon DROIDX 1980 erneut automatisch, bis um 15:02:40 Uhr die Meldung „Gerät wird deaktiviert (Grund: „Verbindung entfernt“) [38]“ erscheint.

Die Fragen, die ich an dieser Stelle habe, sind:

Gibt es in den Zeilen 7622–7625 und anderen kurzen Lücken interessante Informationen?

Warum „40:fc:89:29:82:fb (SSID='Verizon DROIDX 1980' freq=2462 MHz)“ und „f8:7b:7a:4f:8f:56 (SSID='Verizon DROID2 6182' freq=2437 MHz)“ verwenden? Welches ist richtig?

Sind Sie wirklich, wirklich, wirklich sicher, dass Sie den WPA-Preshared-Key richtig eingegeben haben? Wenn es sich um eine Hex-Zeichenfolge handelt, versuchen Sie, [af] durch [AF] oder andersherum zu ersetzen.

Waltinator

Antwort4

Ich habe ein ähnliches Problem auf meinem Notebook festgestellt und es passierte jedes Mal, wenn es nicht an das Ladegerät angeschlossen war. Es hatte etwas mit der WLAN-Energieverwaltung zu tun. Anscheinend musste ich es dauerhaft ausschalten.

verwandte Informationen