Unable to connect to WEP encrypted network when using iwl3945 module (but success when using ipw3945)

I'm seeing the same thing as well with WEP 64 bit authentication. This is on a Dell 1420 laptop.
ipw3945 works but the connection is prone to freezing as documented on Dell's website. Below is the lspci and dmesg output. Please let me know if you need any more information to debug this problem.

sgoel@dell-desktop:~$ uname -a
Linux dell-desktop 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux

lspci output:

0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
        Subsystem: Intel Corporation Unknown device 1020
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at fe8ff000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: <access denied>

Dmesg output:

[ 64.800000] wlan0: Initial auth_alg=0
[ 64.800000] wlan0: authenticate with AP 00:13:10:b5:3e:8c
[ 64.800000] wlan0: RX authentication from 00:13:10:b5:3e:8c (alg=0 transaction=2 status=0)
[ 64.800000] wlan0: authenticated
[ 64.800000] wlan0: associate with AP 00:13:10:b5:3e:8c
[ 64.804000] wlan0: RX AssocResp from 00:13:10:b5:3e:8c (capab=0x611 status=18 aid=1)
[ 64.804000] wlan0: AP denied association (code=18)
[ 64.836000] wlan0: RX AssocResp from 00:13:10:b5:3e:8c (capab=0x611 status=18 aid=1)
[ 64.836000] wlan0: AP denied association (code=18)
[ 64.868000] wlan0: RX AssocResp from 00:13:10:b5:3e:8c (capab=0x611 status=18 aid=1)
[ 64.868000] wlan0: AP denied association (code=18)
[ 64.900000] wlan0: RX AssocResp from 00:13:10:b5:3e:8c (capab=0x611 status=18 aid=1)
[ 64.900000] wlan0: AP denied association (code=18)
[ 64.932000] wlan0: RX AssocResp from 00:13:10:b5:3e:8c (capab=0x611 status=18 aid=1)
[ 64.932000] wlan0: AP denied association (code=18)
[ 65.000000] wlan0: associate with AP 00:13:10:b5:3e:8c
[ 65.000000] wlan0: RX AssocResp from 00:13:10:b5:3e:8c (capab=0x611 status=18 aid=1)
[ 65.000000] wlan0: AP denied association (code=18)
[ 65.032000] wlan0: RX AssocResp from 00:13:10:b5:3e:8c (capab=0x611 status=18 aid=1)
[ 65.032000] wlan0: AP denied association (code=18)
[ 65.064000] wlan0: RX AssocResp from 00:13:10:b5:3e:8c (capab=0x611 status=18 aid=1)
[ 65.064000] wlan0: AP denied association (code=18)
[ 65.096000] wlan0: RX AssocResp from 00:13:10:b5:3e:8c (capab=0x611 status=18 aid=1)
[ 65.096000] wlan0: AP denied association (code=18)
[ 65.200000] wlan0: associate with AP 00:13:10:b5:3e:8c
[ 65.200000] wlan0: RX AssocResp from 00:13:10:b5:3e:8c (capab=0x611 status=18 aid=1)
[ 65.200000] wlan0: AP denied association (code=18)
[ 65.400000] wlan0: association with AP 00:13:10:b5:3e:8c timed out
[ 212.648000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 344.820000] ADDRCONF(NETDEV_UP): wlan0: link is not ready

It seems that there are issues connecting to a WPA (not WPA2) encrypted network as well. On the off chance that the router(s) themselves have something to do with it, the test configurations I've used are as follows:

Linksys router using WPA2 encryption worked fine (albeit with reduced signal strength--a known bug)
Belkin router using WPA2 encryption worked fine (albeit with reduced signal strength--a known bug)
Netgear router using 128-bit WEP and (after firmware flash/hack) using WPA, could not be authenticated/associated.

These scenarios are the same when using x86 or AMD64 versions of Gutsy.

As my experience with ipw3945 under the AMD64 version has been terrible--it doesn't seem to work at all--this is a showstopper bug on that platform since it's the only module for this chipset.

It looks like a fix has been implemented in the modules in Hardy (alpha 2). I am posting this from the AMD64 live cd I just burned, on the wireless network I have not been able to connect to while in my Gutsy installation. Any chance this will find its way into backports (or a more appropriate repo)?

I can confirm a rather similar behaviour on my D630 with Gutsy. The ip3845 does not work in a stable manner and the iwl3945 is not able to join WEP protected access points.

Here is an excerpt form the syslog:
Jan 14 06:58:54 w2fz2wqq01 kernel: [ 626.900000] wlan0: RX AssocResp from 00:80:c8:38:64:79 (capab=0x11 status=18 aid=0)
Jan 14 06:58:54 w2fz2wqq01 kernel: [ 626.900000] wlan0: AP denied association (code=18)
Jan 14 06:58:54 w2fz2wqq01 kernel: [ 627.100000] wlan0: associate with AP 00:80:c8:38:64:79
Jan 14 06:58:54 w2fz2wqq01 kernel: [ 627.100000] wlan0: RX AssocResp from 00:80:c8:38:64:79 (capab=0x11 status=18 aid=0)
Jan 14 06:58:54 w2fz2wqq01 kernel: [ 627.100000] wlan0: AP denied association (code=18)
Jan 14 06:58:54 w2fz2wqq01 kernel: [ 627.300000] wlan0: association with AP 00:80:c8:38:64:79 timed out
Jan 14 06:58:57 w2fz2wqq01 kernel: [ 629.660000] wlan0: RX deauthentication from 00:80:c8:38:64:79 (reason=16)
Jan 14 06:58:57 w2fz2wqq01 kernel: [ 629.660000] wlan0: deauthenticated
Jan 14 06:58:59 w2fz2wqq01 NetworkManager: <info> Old device 'wlan0' activating, won't change.
Jan 14 06:59:06 w2fz2wqq01 kernel: [ 639.444000] wlan0: privacy configuration mismatch and mixed-cell disabled - disassociate
Jan 14 06:59:11 w2fz2wqq01 NetworkManager: <info> Old device 'wlan0' activating, won't change.
Jan 14 06:59:14 w2fz2wqq01 kernel: [ 647.204000] wlan0: privacy configuration mismatch and mixed-cell disabled - disassociate

It seems to work fine with access point without any encryption method.

This has been broken for a while and I do not see any feedback from the maintainers and it looks like a critical bug to me. If you need any additional information, I'll be more than happy to provide it but please do provide some sense of what is being done to address this. Thanks.

I don't know if it is related to the iwl3945 or ipw3945, but I'm running 7.10 on a dell cpi d266xp with a 3com-card and it lights and blinks quite a lot and almost connects to a non-secure network.

I agree with Goel that this is a critical bug, so I hope I am contributing with dumps from dmesg, uname and syslog.

dmesg | grep rename:
[ 202.100000] wlan0_rename: Initial auth_alg=0
[ 202.100000] wlan0_rename: authenticate with AP 00:02:72:59:e1:60
[ 202.112000] wlan0_rename: RX authentication from 00:02:72:59:e1:60 (alg=0 transaction=2 status=0)
[ 202.112000] wlan0_rename: authenticated
[ 202.112000] wlan0_rename: associate with AP 00:02:72:59:e1:60
[ 202.116000] wlan0_rename: invalid aid value 5; bits 15:14 not set
[ 202.116000] wlan0_rename: RX AssocResp from 00:02:72:59:e1:60 (capab=0x401 status=0 aid=5)
[ 202.116000] wlan0_rename: associated
[ 252.872000] wlan0_rename: disassociate(reason=3)
[ 442.632000] wlan0_rename: Initial auth_alg=0
[ 442.632000] wlan0_rename: authenticate with AP 00:02:72:59:e1:60
[ 442.636000] wlan0_rename: RX authentication from 00:02:72:59:e1:60 (alg=0 transaction=2 status=0)
[ 442.636000] wlan0_rename: authenticated
[ 442.636000] wlan0_rename: associate with AP 00:02:72:59:e1:60
[ 442.636000] wlan0_rename: invalid aid value 5; bits 15:14 not set
[ 442.636000] wlan0_rename: RX AssocResp from 00:02:72:59:e1:60 (capab=0x401 status=0 aid=5)
[ 442.636000] wlan0_rename: associated
[ 490.824000] wlan0_rename: disassociate(reason=3)
[ 1887.540000] wlan0_rename: Initial auth_alg=0
[ 1887.540000] wlan0_rename: authenticate with AP 00:02:72:59:e1:60
[ 1887.548000] wlan0_rename: RX authentication from 00:02:72:59:e1:60 (alg=0 transaction=2 status=0)
[ 1887.548000] wlan0_rename: authenticated
[ 1887.548000] wlan0_rename: associate with AP 00:02:72:59:e1:60
[ 1887.552000] wlan0_rename: invalid aid value 5; bits 15:14 not set
[ 1887.552000] wlan0_rename: RX AssocResp from 00:02:72:59:e1:60 (capab=0x401 status=0 aid=5)
[ 1887.552000] wlan0_rename: associated
[ 1934.232000] wlan0_rename: disassociate(reason=3)
[ 3053.516000] wlan0_rename: Initial auth_alg=0
[ 3053.516000] wlan0_rename: authenticate with AP 00:02:72:59:e1:60
[ 3053.520000] wlan0_rename: RX authentication from 00:02:72:59:e1:60 (alg=0 transaction=2 status=0)
[ 3053.520000] wlan0_rename: authenticated
[ 3053.520000] wlan0_rename: associate with AP 00:02:72:59:e1:60
[ 3053.528000] wlan0_rename: invalid aid value 5; bits 15:14 not set
[ 3053.528000] wlan0_rename: RX AssocResp from 00:02:72:59:e1:60 (capab=0x401 status=0 aid=5)
[ 3053.528000] wlan0_rename: associated
[ 3100.568000] wlan0_rename: disassociate(reason=3)

uaname -a:
Linux D266XT 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

lspci -v:
01:00.0 Network controller: 3Com Corporation 3com 3CRWE154G72 [Office Connect Wireless LAN Adapter] (rev 01)
 Subsystem: 3Com Corporation 3com 3CRWE154G72 [Office Connect Wireless LAN Adapter]
 Flags: bus master, medium devsel, latency 64, IRQ 11
 Memory at 24000000 (32-bit, non-prefetchable) [size=8K]
 Capabilities: [dc] Power Management version 1

Hope this information helps developers and others.

If I have posted this in the wron...

Hello again,

(tried to edit the message above, but since that wasn't possible, I add a new comment).
I noticed in the logs that there was a session running. I killed that one and choose an open network again. This time it connected. So it seems that NM or something does not kill connections to well.
(Maybe that is another bug)

Keep up the good work all. Linux / Ubuntu is getting better and better.

Best

Trond

This is also a problem in Hardy. I'm marking it as such. I've tried two different networks and it just keeps asking for the password over and over if it's WEP.

Hi Mackenzie, thanks for testing Hardy. For anyone else interested, the Hardy Heron Alpha series is currently under development and contains an updated version of the kernel. It would be helpful if everyone else could test the latest Hardy Alpha release: http://www.ubuntu.com/testing . You should be able to then test the new kernel via the LiveCD. Then, per the kernel team's bug policy, can you please attach the following information. Please be sure to attach each file as a separate attachment.

* cat /proc/version_signature > version.log
* dmesg > dmesg.log
* sudo lspci -vvnn > lspci-vvnn.log

It would be good to capture the dmesg output after you notice the issue as it may have logged some useful error messages for debugging. For more information regarding the kernel team bug policy, please refer to https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks again and we appreciate your help and feedback.

kvaneesh@skywalker:~$cat /proc/version_signature
Ubuntu 2.6.24-12.22-generic

Latest driver from http://linuxwireless.org/en/users/Download fix the issue.

[ 108.302649] wlan0_rename: Initial auth_alg=0
[ 108.302659] wlan0_rename: authenticate with AP 00:30:bd:c3:c5:da
[ 108.304724] wlan0_rename: RX authentication from 00:30:bd:c3:c5:da (alg=0 transaction=2 status=0)
[ 108.304733] wlan0_rename: authenticated
[ 108.304738] wlan0_rename: associate with AP 00:30:bd:c3:c5:da
[ 108.306774] wlan0_rename: RX AssocResp from 00:30:bd:c3:c5:da (capab=0x11 status=0 aid=1)
[ 108.306781] wlan0_rename: associated
[ 108.310118] ADDRCONF(NETDEV_CHANGE): wlan0_rename: link becomes ready

Hi Everyone,

An updated version of the iwlwifi drivers (version 1.2.25) was recently added to the linux-backports-modules-2.6.24 package. It would be good if you could retest with lbm once it is published and available: https://edge.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.24/ . Thanks.

Did a dist-upgrade today and it doesn't work. relevant dmesg

[ 139.109142] wlan0_rename: Initial auth_alg=128
[ 139.109153] wlan0_rename: authenticate with AP 00:16:47:5c:e5:40
[ 139.109179] wlan0_rename: privacy configuration mismatch and
mixed-cell disabled - disassociate
[ 139.110764] wlan0_rename: RX authentication from 00:16:47:5c:e5:40
(alg=128 transaction=2 status=0)
[ 139.110768] wlan0_rename: authenticated
[ 139.110770] wlan0_rename: associate with AP 00:16:47:5c:e5:40
[ 139.110772] wlan0_rename: mismatch in privacy configuration and
mixed-cell disabled - abort association
[ 139.112378] wlan0_rename: RX deauthentication from
00:16:47:5c:e5:40 (reason=2)
[ 139.112380] wlan0_rename: deauthenticated
[ 139.163874] wlan0_rename: privacy configuration mismatch and
mixed-cell disabled - disassociate
[ 139.165001] wlan0_rename: RX deauthentication from
00:16:47:5c:e5:40 (reason=2)

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-============================-============================-========================================================================
ii linux-backports-modules-2.6. 2.6.24-12.9 Ubuntu
supplied Linux modules for version 2.6.24 on x86/x86_64
ii linux-backports-modules-2.6. 2.6.24-14.11 Ubuntu
supplied Linux modules for version 2.6.24 on x86/x86_64
ii linux-backports-modules-hard 2.6.24.14.16 Generic
Linux backported drivers.
ii linux-backports-modules-hard 2.6.24.14.16
Backported drivers for generic kernel image

kvaneesh@skywalker:~$modinfo iwl3945
filename:
/lib/modules/2.6.24-14-generic/updates/wireless/iwlwifi/iwlwifi/compatible/iwl3945.ko
license: GPL
author: Copyright(c) 2003-2007 Intel Corporation
version: 1.2.25
description: Intel(R) PRO/Wireless 3945ABG/BG Network Connection
driver for Linux
srcversion: FDE2E62843DE3ED112A50C3
alias: pci:v00008086d00004227sv*sd*bc*sc*i*
alias: pci:v00008086d00004222sv*sd*bc*sc*i*
depends: led-class,iwlwifi_mac80211
vermagic: 2.6.24-14-generic SMP mod_unload 586
parm: antenna:select antenna (1=Main, 2=Aux, default 0 [both]) (int)
parm: disable:manually disable the radio (default 0 [radio on]) (int)
parm: hwcrypto:using hardware crypto engine (default 0 [software])
 (int)
parm: debug:debug output mask (int)
parm: disable_hw_scan:disable hardware scanning (default 0) (int)
parm: queues_num:number of hw queues. (int)
parm: qos_enable:enable all QoS functionality (int)

The one worked has

kvaneesh@skywalker:~/tmp/compat-wireless-2008-03-28/drivers/net/wireless/iwlwifi$modinfo
./iwl3945.ko
filename: ./iwl3945.ko
license: GPL
author: Copyright(c) 2003-2008 Intel Corporation
version: 1.2.26k
description: Intel(R) PRO/Wireless 3945ABG/BG Network Connection
driver for Linux
srcversion: 585C929DA556871F8192D44
alias: pci:v00008...

I am having the SAME problems attaching to a WEP 128 wireless network. This all works fine with Fiesty, Gutsy and IPW3945 module. This has NEVER worked for me with Hardy Heron 8.04 LTS beta or now the updated release candidate updated and installed 4/19/2008. I have a Dell D520 and will provide any info needed to help resolve this problem.

I'd install the IPW3945 drivers if that would work and I could find them.

I'm hosting a Hardy Release party this week and I REALLY need help to get this working on my laptop. I agree with earlier comments that this is a critical bug.

I used to be able to connect to a WEP wireless network with Gutsy. Hardy simply does not work.

FIY:

Running Dell Inspiron 6400 with Hardy:

~ % sudo linuxinfo
Linux duo 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008
Two Intel Unknown 1000MHz processors, 6653.73 total bogomips, 1002M RAM
System library 2.7.0

Relevant "lspci -v":

0b:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
        Subsystem: Intel Corporation Unknown device 1021
        Flags: bus master, fast devsel, latency 0, IRQ 221
        Memory at efdff000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [c8] Power Management version 2
        Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
        Capabilities: [e0] Express Legacy Endpoint IRQ 0

Attached is the output of
 ~ % sudo modinfo iwl3945.

[...]

I still need to try the download from the intel sources. Will report later what happens.

Hello again (I am the author of the last post),

Installing "linux-backports-modules-2.6.24-16-generic" solved the problem.

The new version of the driver iwl3945 solved it.

 ~ % sudo modinfo iwl3945 | grep srcversion
srcversion: FDE2E62843DE3ED112A50C3

Thank you, Thank you, Thank you Francisco!!!

I am able to connect now using WEP and the iwl3945 ver 1.2.25 that was included in the solution you provided. I tried installing from add/remove, but could not find the package. So I updated from the command line:

sudo apt-get install linux-backports-modules-2.6.24-16-generic

Now I have -
license: GPL
author: Copyright(c) 2003-2007 Intel Corporation
version: 1.2.25
description: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux
srcversion: FDE2E62843DE3ED112A50C3

I hope this will be the version included with Hardy Heron when released this week on 4/24/2008!

I can confirm that I am able to connect to a WEP64 encypted network using the backports modules with Hardy.

Thanks.

For what it's worth, this problem has nothing to do with password authentication. I had the same problem on a totally open network. Fortunately the backports-modules fixed everything for me.

Obviously I'd like to nominate this fix for a mainline update.

Marking this "Fix Released" against the linux-backports-modules-2.6.24 package as there are multiple comments here verifying it resolves the issue. Also Mathew, the original bug reporter, made a comment this was resolved in Hardy for him. Thanks.

Neither lbm's 1.2.25 nor lum 1.2.0 work for me when connecting to WEP wireless when using hex/ascii key. Switching from iwlwifi to ipw3945 or ndiswrapper solves this problem.

WPA has always worked and continues to do so. I am running kubuntu hardy 64 bit kde 3.5 edition. I can provide additional logs upon request.

Both WPA and WEP give the following dmesg output:

[ 112.179545] wlan0: authenticate with AP 00:1b:2f:61:32:de
[ 112.181291] wlan0: Initial auth_alg=0
[ 112.181300] wlan0: authenticate with AP 00:1b:2f:61:32:de
[ 112.181325] wlan0: RX authentication from 00:1b:2f:61:32:de (alg=0 transaction=2 status=0)
[ 112.181329] wlan0: authenticated
[ 112.181334] wlan0: associate with AP 00:1b:2f:61:32:de
[ 112.183815] wlan0: authentication frame received from 00:1b:2f:61:32:de, but not in authenticate state - ignored
[ 112.184673] wlan0: authentication frame received from 00:1b:2f:61:32:de, but not in authenticate state - ignored
[ 112.185437] wlan0: RX deauthentication from 00:1b:2f:61:32:de (reason=6)
[ 112.185443] wlan0: deauthenticated
[ 112.428961] wlan0: authenticate with AP 00:1b:2f:61:32:de
[ 112.430695] wlan0: RX authentication from 00:1b:2f:61:32:de (alg=0 transaction=2 status=0)
[ 112.430703] wlan0: authenticated
[ 112.430707] wlan0: associate with AP 00:1b:2f:61:32:de
[ 112.433036] wlan0: RX AssocResp from 00:1b:2f:61:32:de (capab=0x431 status=0 aid=2)
[ 112.433045] wlan0: associated
[ 112.630289] wlan0: No ProbeResp from current AP 00:1b:2f:61:32:de - assume out of range
[ 113.055003] wlan0: No STA entry for own AP 00:1b:2f:61:32:de
[ 113.056157] wlan0: Initial auth_alg=0
[ 113.056170] wlan0: authenticate with AP 00:1b:2f:61:32:de
[ 113.057968] wlan0: Initial auth_alg=0
[ 113.057977] wlan0: authenticate with AP 00:1b:2f:61:32:de
[ 113.058729] wlan0: RX authentication from 00:1b:2f:61:32:de (alg=0 transaction=2 status=0)
[ 113.058738] wlan0: authenticated
[ 113.058742] wlan0: associate with AP 00:1b:2f:61:32:de
[ 113.059889] wlan0: RX ReassocResp from 00:1b:2f:61:32:de (capab=0x431 status=0 aid=2)
[ 113.059897] wlan0: associated
[ 117.729409] wlan0: deauthenticate(reason=3)
[ 117.942699] wlan0: privacy configuration mismatch and mixed-cell disabled - disassociate
[ 118.334786] wlan0: privacy configuration mismatch and mixed-cell disabled - disassociate
[ 119.211340] wlan0: RX deauthentication from 00:1b:2f:61:32:de (reason=7)
[ 119.211350] wlan0: deauthenticated
[ 119.211358] wlan0: RX deauthentication from 00:1b:2f:61:32:de (reason=7)
[ 119.211365] wlan0: RX deauthentication from 00:1b:2f:61:32:de (reason=7)
[ 119.211373] wlan0: RX deauthentication from 00:1b:2f:61:32:de (reason=7)
[ 119.211380] wlan0: RX deauthentication from 00:1b:2f:61:32:de (reason=7)
[ 119.211387] wlan0: RX deauthentication from 00:1b:2f:61:32:de (reason=7)
[ 119.211394] wlan0: RX deauthentication from 00:1b:2f:61:32:de (reason=7)
[ 119.211401] wlan0: RX deauthentication from 00:1b:2f:61:32:de (reason=7)
[ 119.211407] wlan0: RX deauthentication from 00:1b:2f:61:32:de (reason=7)
[ 119.211414] wlan0: RX deauthentication from 00:1b:2f:61:32:de (reason=7)
[ 119.211421] wlan0: RX deauthentication from 00:1b:2f:61:32:de (r...

Same problem here.

[ 6951.725704] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.0
[ 6951.725713] iwl3945: Copyright(c) 2003-2007 Intel Corporation
[ 6951.725875] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 18 (level, low) -> IRQ 18
[ 6951.725902] PCI: Setting latency timer of device 0000:03:00.0 to 64
[ 6951.726985] iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
[ 6951.822744] iwl3945: Tunable channels: 13 802.11bg, 12 802.11a channels
[ 6951.824125] wmaster0: Selected rate control algorithm 'iwl-3945-rs'
[ 6951.830518] udev: renamed network interface wlan0 to eth1
[ 6951.852097] ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 6952.951841] eth1: Initial auth_alg=0
[ 6952.951853] eth1: authenticate with AP 00:80:c6:e3:e2:94
[ 6952.954293] eth1: RX authentication from 00:80:c6:e3:e2:94 (alg=0 transaction=2 status=0)
[ 6952.954302] eth1: authenticated
[ 6952.954306] eth1: associate with AP 00:80:c6:e3:e2:94
[ 6952.957740] eth1: RX AssocResp from 00:80:c6:e3:e2:94 (capab=0x51 status=18 aid=1)
[ 6952.957748] eth1: AP denied association (code=18)
[ 6953.153713] eth1: associate with AP 00:80:c6:e3:e2:94
[ 6953.157167] eth1: RX AssocResp from 00:80:c6:e3:e2:94 (capab=0x51 status=18 aid=1)
[ 6953.157176] eth1: AP denied association (code=18)
[ 6953.353595] eth1: associate with AP 00:80:c6:e3:e2:94
[ 6953.358926] eth1: RX AssocResp from 00:80:c6:e3:e2:94 (capab=0x51 status=18 aid=1)
[ 6953.358936] eth1: AP denied association (code=18)
[ 6953.553513] eth1: association with AP 00:80:c6:e3:e2:94 timed out

Installation of linux-backports-modules-hardy-generic solved the problem.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.