[jaunty][iwl3945] WPA fully associate only after many retries
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Linux |
Fix Released
|
Medium
|
|||
| linux (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Bug Description
Connecting to a WPA-PSK wireless access point (AP), a Billion 5100W with non-hidden SSID, using a Dell Latitude D830, with an Intel PRO/Wireless 3945ABG device using the iwl3945 driver, will only associate after several retries.
Initially, after installing 8.10 on the said laptop, WPA worked fine with this setup. After upgrading to 9.04 a month has elapsed before I used the wireless link again and at that time I have noticed degraded association behaviour. Network manager was unusable as it timed out so often it was easier to use wpa_supplicant, which retries indefinitely, from the terminal. Association now takes anywhere from 2mins to over 6 hours (leaving it running over night, trying to connect), most often taking over 10mins.
Connection to the same AP using a secondary D-Link AirPlusG (DWL-G630) as wlan1, using the same /etc/wpa_
Before wpa_supplicant finally connects it continuously retries, each retry having one of 3 possible failure cases I have detected thus far (I have been logging this for over a month now). I am not sure if this is all part of the same issue, but they all contribute to a non-connection. I will attach the annotated output of wpa_supplicant for each case separately. I have found this output far more detailed than that in syslog, but will include a syslog file with a corresponding wpa_supplicant file as an additional example.
Failure case 1: No authentication for 10secs
A successful AP scan, but no association for 10secs causes a retry.
Failure case 2: A possible disconnect by the AP?
A successful AP scan, then association event (no WPA handshake yet), but 6 seconds later a "Wireless event: cmd=0x8b15 len=20" causes a disconnect and retry.
Failure case 3: Timeout during 4way handshake
A successful AP scan, association, but timeout occurs during the 4-way handshake
Device information:
>lspci (only relevant lines listed; first device working, second device problematic)
04:00.0 Network controller: RaLink RT2561/RT61 rev B 802.11g
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
>lsmod | grep iwl3945
iwl3945 97912 0
mac80211 217592 3 rt2x00pci,
led_class 12036 2 rt2x00lib,iwl3945
cfg80211 38288 3 rt2x00lib,
>modinfo iwl3945
filename: /lib/modules/
firmware: iwlwifi-
license: GPL
author: Copyright(c) 2003-2008 Intel Corporation
version: 1.2.26ks
description: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux
srcversion: 2B0F90BC6D81899
alias: pci:v00008086d0
alias: pci:v00008086d0
alias: pci:v00008086d0
alias: pci:v00008086d0
alias: pci:v00008086d0
alias: pci:v00008086d0
depends: mac80211,
vermagic: 2.6.28-14-generic SMP mod_unload modversions 586
>modinfo mac80211
filename: /lib/modules/
license: GPL
description: IEEE 802.11 subsystem
srcversion: 1F1657BC4ED0F54
depends: cfg80211
vermagic: 2.6.28-14-generic SMP mod_unload modversions 586
parm: ieee80211_
>cat /etc/wpa_
network={
proto=WPA
scan_ssid=1
#PSK unencrypted: "xxxxxxxx"
ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
HibernationDevice: RESUME=
MachineType: Dell Inc. Latitude D830
NonfreeKernelMo
Package: linux-image-
ProcCmdLine: root=UUID=
ProcEnviron:
LANGUAGE=en_GB:en
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
ProcVersionSign
SourcePackage: linux
| Christhonie (christhonie) wrote | #1 |
| Christhonie (christhonie) wrote | #2 |
| Christhonie (christhonie) wrote | #3 |
| Christhonie (christhonie) wrote | #4 |
| Christhonie (christhonie) wrote | #5 |
| Christhonie (christhonie) wrote | #6 |
| Changed in linux: | |
| status: | Unknown → Fix Released |
| ^_Pepe_^ (jose-angel-fernandez-freire) wrote | #7 |
| tags: | added: jaunty |
| Changed in linux (Ubuntu): | |
| status: | New → Incomplete |
| Christhonie (christhonie) wrote | #8 |
| ^_Pepe_^ (jose-angel-fernandez-freire) wrote | #9 |
| Changed in linux (Ubuntu): | |
| status: | Incomplete → Invalid |
| Changed in linux: | |
| importance: | Unknown → Medium |
Created attachment 333065
syslogd log
Description of problem:
NetworkManager doesn't always connect to Network
Version-Release number of selected component (if applicable):
NetworkManager-
wpa_supplicant-
kernel-
How reproducible:
Intermittent
Steps to Reproduce:
Either
1. Resume suspended laptop
2. wait for NM to connect to previously selected SSID
3. observe that NM fails & pops up request for secrets
or
1. Start with NM already connected to an AP
2. Select an alternate (but correctly configured, and available) AP
3. observe that NM fails &^ pops up secrets request
Actual results:
NM fails to connect
Expected results:
NM connects
Additional info:
Basically sometimes this works, sometimes it doesn't. Association appears to time out. Other non-linux clients (S60/Nokia N95 8Gb/Nokia N96/Windows 7/Windows Vista) don't *appear* to have a problem
In the log file attached note the "jonesn: " messages in the log. These were created with the "logger" command to aid in documenting the scenario
The Ap that I had been connected to ok was "planetf1c". The one that failed was "planetf1f". Ignore "planetf1e" -- this one is not active and I clicked on it in the GUI by mistake.
Error seems to hinge around
Activation (wlan0/wireless): association took too long.
Security in use is WPA2-PSK AES
wifi driver is iwl3945
Both AP are "fonera" routers running openwrt with atheros wireless. In this config the router broadcasts 2 SSIDs.
Same problem has been observed with ddwrt (single SSID)
Log file is attached (kernel debug log, -dddt )
Not entirely clear if the issue is supplicant, NM or driver.....
Final note:
I am also seeing issues with WPA Enterprise (LEAP and EAP-TLS) but figure it makes sense to address the simpler PSK case first (less variables, more control home vs enterprise...)