WLAN disconnects repeatedly from AP when using WPA on a SMP machine

I get the same sort of behaviour with Dapper w/ kernel 2.6.15-26-686 (SMP) on a Dell Inspiron 9400 (ipw3945), however I use (for the moment) WEP.

Do you believe this to be WPA specific?

I'm running Dapper on a Dell Inspiron 640m with the same ipw3945 driver. My Access point is a LinkSys configured with an hidden SSID and WEP. After installing the latest updates, I'm having a similar issue.

With linux-image-2.6.15-26-686 (2.6.15-26.47) and linux-restricted-modules-2.6.15-26-686 (2.6.15.11-4), I'm unable to stay connected to the AP. It connects and then deconnects after 10-30s. I have to do a ifup/ifdown to reconnect.

With linux-image.2.6.15-27-686 (2.6.15-27.48) and linux-restricted-modules-2.6.15-27-686 (2.5.15.11-5), I am not able to connect at all to the AP.

Downgrading back to linux-image-2.6.15-26-686 (2.6.15-26.46) and linux-restricted-modules-2.6.15-26-686 (2.6.15.11-3) makes everything works as before. (This may be a different issue.)

I read from the 2.6.15-26.47 changelog that it included a fix for a WEP race, that's why I'm reporting this here, since it seems to be the most logical culprit.

In the previous message, the "This may be a different issue." comment applies to the paragraph about 2.6.15-27.48. So it should read:

With linux-image.2.6.15-27-686 (2.6.15-27.48) and linux-restricted-modules-2.6.15-27-686 (2.5.15.11-5), I am not able to connect at all to the AP. (This may be a different issue.)

Downgrading back to linux-image-2.6.15-26-686 (2.6.15-26.46) and linux-restricted-modules-2.6.15-26-686 (2.6.15.11-3) makes everything works as before.

I also have a Dell Inspirion 640m (w/ smp) on Ubuntu Edgy Eft and I currently have frequent "Host not found" errors and disconnections (especially when the webpage has a lot of images). Also, I have to manually set the essid and wep key "after" I boot; I use a shell script to run iwconfig and dhclient after login, but I'd like to see a more permanent fix.

Is my problem relevant to this bug? I'm sort of new to reporting bugs.

I'm seeing this problem on Debian, Kernel 2.6.18, Core Duo, ipw3945 (Dell 640m).
The tuxyturvy link seems to have many details.

In the 2.6.20 changelog there are some changesets that seem to be relevant.

commit 4d1feabcbf41f875447a392015acd0796f57baf6
Author: Ulrich Kunitz <email address hidden>
Date: Sun Dec 10 11:13:12 2006 -0800

    [PATCH] zd1211rw: Call ieee80211_rx in tasklet

    The driver called ieee80211_rx in hardware interrupt context. This has
    been against the intention of the ieee80211_rx function. It caused a bug
    in the crypto routines used by WPA. This patch calls ieee80211_rx in a
    tasklet.

    Signed-off-by: Ulrich Kunitz <email address hidden>
    Signed-off-by: Andrew Morton <email address hidden>
    Signed-off-by: John W. Linville <email address hidden>

That changeset could maybe be fixing this. I havn't investigated it further. I'll compile 2.6.20 myself and see if that fixes the wireless stability again.

Does "Fix Committed" mean that I shouldn't be seeing this? 'Cause I do, this on Feisty with 2.6.20-16-generic. Large file tranfers over wifi break, confusing the wifi setup. Interestingly enough, resetting the access point allows me to restore things (by rerunning iwconfig/dhclient on the client). However, I've seen this happen on several different access points now, from three different vendors (Apple, Billion, and D-link). Less intensive use (web browsing) cause no problems, it seems.

It may be related to encryption, I've only tested this with WEP (both short and long keys).

Reducing the bandwidth to 2Mbit seems to alleviate the problem a bit, but I'm unable to make the setting "stick", it gets reset to max at regular intervals.

After the network is broken, I noticed that I couldn't make my wifi card associate with the AP, repeated iwconfigs would mostly display "not associated", and only occasionally the AP MAC address - which would then disappear at the next invocation. dhclient would broadcast, but never get any replies.

This is on a Core 2 Duo Dell 620m. I haven't tested the maxcpus option to see if the problem is related to SMP.

This bug was marked 'Fix Committed' a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue? If not, we'd like to flip the status to "Fix Released". If it is still an issue could you please test the recent Hardy Heron Alpha series was recently released. It contains an updated version of the kernel. You can download and try the new Hardy Heron Alpha release from http://cdimage.ubuntu.com/releases/hardy/ . You should be able to then test the new kernel via the LiveCD. If you can, please verify if this bug still exists or not and report back your results. General information regarding the release can also be found here: http://www.ubuntu.com/testing/ . Thanks

I'm using Hardy Heron alpha 5 on Toshiba Satellite 1130-S155 with SMC2632w (atmel chip) pcmcia V3 card.

When I try to use update manager the connection with ap is lost. I've noticed that the wireless signal drops to 0% and then the connection is broken.

Sometimes, browsing the web, it has the same behavior but little time after it restores and goes on.

Using iwconfig i got:

lo no wireless extensions.

eth0 no wireless extensions.

eth1 IEEE 802.11-DS ESSID:"SMC"
          Mode:Managed Frequency:2.437 GHz Access Point: 00:04:E2:88:45:D4
          Bit Rate:11 Mb/s
          Retry short limit:7 RTS thr:off Fragment thr:off
          Power Management:off
          Link Quality:0 Signal level:0 Noise level:0
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:2021

Using sudo lspci | grep Atmel (driver for my card) i got:

[ 115.018919] eth1: Atmel at76c50x. Version 0.98. MAC 00:04:e2:7b:30:37
[ 115.631228] ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 128.206035] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 142.583087] eth1: no IPv6 routers present
[ 928.983210] ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 931.350137] ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 963.570177] ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 966.294807] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 981.866677] eth1: no IPv6 routers present
[ 1020.135966] ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 1098.286502] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 1116.563400] eth1: no IPv6 routers present
[ 1168.517763] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 1209.009053] eth1: no IPv6 routers present

I couldn't make it work with gutsy.

Hi mvavallo,

It seems you are experiencing a slightly different bug than what was originally reported. Please open a new bug report. Per the kernel team's bug policy, in that new report please attach the following information. Please be sure to attach each file as a separate attachment.

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

For more information regarding the kernel team bug policy, please refer to https://wiki.ubuntu.com/KernelTeamBugPolicies .

Since there was no other feedback regarding 2.6.17, I'm going to go ahead and close it. Thanks.