Red Hat Bugzilla – Bug 449220
ipw2200 on Dell Inspiron 6000 sometimes doesn't connect
Last modified: 2013-01-10 02:55:54 EST
Description of problem:
After upgrading to RHEL 5.2/kernel kernel-2.6.18-92.el5 the WLAN interface is
sometimes unable to connect to the network. This always happens after resume
from suspend to disk, but sometimes also after normal boot.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. upgrade the machine to RHEL 5.2
2. try to connect to a WLAN
should be able to connect
WLAN is secured with WPA. Didn't try other security settings.
Going back to the latest RHEL 5.1 kernel fixes the problem. Last kernel used:
Error message in /var/log/messages:
May 31 15:57:01 ws-heike NetworkManager: <information> Activation (eth1) Stage
2 of 5 (Device Configure) complete.
May 31 15:57:21 ws-heike NetworkManager: <information> Activation
(eth1/wireless): association took too long (>20s), failing activation.
May 31 15:57:21 ws-heike NetworkManager: <information> Activation (eth1)
May 31 15:57:21 ws-heike NetworkManager: <information> Activation (eth1) failed
for access point (<COMMENT: removed>)
May 31 15:57:21 ws-heike NetworkManager: <information> Activation (eth1) failed.
May 31 15:57:21 ws-heike NetworkManager: <information> Deactivating device eth1.
it was quite difficult doing all the tests. I started with .77 as you
recommended, but ended up to test most of the kernels between .53 and .92.
.53 - usually works without any problems
.65 - usually works without any problems, currently in use
.82 - works quite often but not always
.83 - works more often than .82 but less than .65
Works means: WLAN works after boot and after suspend/resume cycle.
I also tested: .77, .75, .79, .81, .84,. 85, .86
They don't even get WLAN working on boot. So, I didn't make any suspend tests.
.68 kernel panics while boot.
Although the outcome isn't quite clear, I hope the information helps and we can
continue to work on this ticket.
Thanks in advance,
Can you try the test kernels here?
Do they perform any better for you?
Can you recreate the issue with the kernels available here?
Please give them a try and post the results here...thanks!
after several hours of testing, I can confirm the following:
The new kernel works much better than .92. After resume from suspend to disk and suspend from ram, the WLAN always worked (tested around 10 times).
But there are still problems after boot. With .53 approx. 80% of the time, connection is restored after boot. With .104 I have to select the WLAN in NetworkManager to get a working connection. It doesn't automatically connect after boot. With .65 I also had to manually reconnect sometimes (approx. 50%).
Summary: .104 works much better, close to .53.
Thank you in advance,
Dan, any thoughts on what might be causing NM to need to "select the WLAN" after boot?
I'm going to make the assumption that if the driver can connect when you tell NM to do it, that this is not a kernel problem. Dan knows how to find me if I'm wrong about that... :-)
Could I get some logs from /var/log/messages from the period before suspend/hibernate, through the period for about 2 mintues after an unsuccessful attempt on wakeup?
I have the same problem on a Dell X1. In my case, I found several dmesg lines like "ipw2200: Failed to send SYSTEM_CONFIG: Already sending a command". I also found this thread for corresponding problem in Ubuntu: https://bugs.launchpad.net/module-init-tools/+bug/264104.
The Ubuntu discussion seems to boil down to that the ipw2200 driver should have other, hardcoded default values. I don't see any remarks about sending patches upstream, though...
WHat I've done is to add WIRELESS_AP_SCANMODE='2' to etc/sysconfig/network-scrips/ifcfg-eth1 and created the file /etc/modprobe.d/ipw2200 containing "options ipw2200 associate=0". For the moment it seems to work. Stay tuned...
I forgot to mention that this is on Fedora 10. Fedora 9 as the same. I update more or less continously.
Well, after some tries I have still no major problems, I get connected and don't have to reboot no and then to get a running network.
However, I'm in the same situation as Christian Bols: after suspend/resume I have to manually select the network, Enclosing /var/log/messages for the suspend/resume cycle.
Some notes: EQUIPAGE is indeed the essid I use. The bak directory holds some scripts I don't run in .../NetworkManager/dispatcher.d (Yes, I run some scripts, but since all is quiet in the logs I presume it isn't the problem.).
Created attachment 327750 [details]
/var/log/messages for suspend/resume cycle
See above. Merry Christmas!
See also bug 477663, possibly related, the same error message occurs in .../messages
For me, this problem is gone. I don't know exactly which update release fixed it, but I don't mind if this gets closed.