Bug 449220

Summary: ipw2200 on Dell Inspiron 6000 sometimes doesn't connect
Product: Red Hat Enterprise Linux 5 Reporter: Christian Jung <cbolz>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED CURRENTRELEASE QA Contact: desktop-bugs <desktop-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.2CC: dcbw, jfeeney, leamas.alec, linville
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-01 17:14:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
/var/log/messages for suspend/resume cycle none

Description Christian Jung 2008-05-31 14:26:52 UTC
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):
ipw2200-firmware-3.0-2.el5
kernel-2.6.18-92.el5

How reproducible:
always

Steps to Reproduce:
1. upgrade the machine to RHEL 5.2
2. try to connect to a WLAN
  
Actual results:
doesn't work

Expected results:
should be able to connect

Additional info:
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:
kernel-2.6.18-53.1.19.el5

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)
failure scheduled... 
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.

Comment 3 Christian Jung 2008-06-19 08:49:03 UTC
HiHo,
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,
Christian

Comment 4 John W. Linville 2008-08-13 15:26:13 UTC
Can you try the test kernels here?

   http://people.redhat.com/linville/kernels/rhel5

Do they perform any better for you?

Comment 5 John W. Linville 2008-08-14 20:07:15 UTC
Can you recreate the issue with the kernels available here?

   http://people.redhat.com/linville/kernels/rhel5/

Please give them a try and post the results here...thanks!

Comment 6 Christian Jung 2008-08-15 08:44:20 UTC
HiHo,
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,
Christian

Comment 7 John W. Linville 2008-08-15 12:40:46 UTC
Dan, any thoughts on what might be causing NM to need to "select the WLAN" after boot?

Comment 8 John W. Linville 2008-08-18 21:11:33 UTC
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... :-)

Comment 9 Dan Williams 2008-10-16 14:00:38 UTC
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?

Comment 10 Alec Leamas 2008-12-23 06:30:41 UTC
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...

Comment 11 Alec Leamas 2008-12-23 07:01:28 UTC
I forgot to mention that this is on Fedora 10. Fedora 9 as the same. I update more or less continously.

Comment 12 Alec Leamas 2008-12-23 12:26:53 UTC
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.).

Comment 13 Alec Leamas 2008-12-23 12:28:03 UTC
Created attachment 327750 [details]
/var/log/messages for suspend/resume cycle

See above. Merry Christmas!

Comment 14 Alec Leamas 2008-12-31 11:22:54 UTC
See also bug 477663, possibly related, the same error message occurs in .../messages

Comment 17 Christian Jung 2010-07-01 16:36:17 UTC
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.