Bug 503983 - Using 5100AGN adapter, cannot connect to WPA2-Enterprise network.
Summary: Using 5100AGN adapter, cannot connect to WPA2-Enterprise network.
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Stanislaw Gruszka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-03 16:58 UTC by August Schwerdfeger
Modified: 2010-09-06 06:47 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-09-06 06:47:07 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
'dmesg' output during initiation and failure. (792 bytes, text/plain)
2009-06-03 16:58 UTC, August Schwerdfeger
no flags Details
Output to '/var/log/messages' during initiation and failure. (5.01 KB, text/plain)
2009-06-03 16:59 UTC, August Schwerdfeger
no flags Details

Description August Schwerdfeger 2009-06-03 16:58:32 UTC
Created attachment 346429 [details]
'dmesg' output during initiation and failure.

Description of problem:

When I connect to a certain WPA2-Enterprise network using an Intel 5100AGN wireless adapter (iwlagn driver), the connection is successfully made, but after only a few seconds ceases to function. This does not appear to register with NetworkManager as a dropped connection.

Using Windows with the 5100AGN adapter, or Fedora with an Intel 3945ABG adapter, I am able to connect to this network without issue.

Using Fedora with the 5100AGN adapter, I am also able to connect without issue to a WPA2-PSK network.

Version-Release number of selected component (if applicable):

kernel: 2.6.29.1-102.fc11.x86_64, 2.6.29.3-155.fc11.x86_64, 2.6.29.4-167.fc11.x86_64
wpa_supplicant: 0.6.8-1.fc11.x86_64
NetworkManager: 0.7.1-4.git20090414.fc11.x86_64

I attach the output of 'dmesg' and the output to '/var/log/messages' during the initiation and failure of the connection.

Comment 1 August Schwerdfeger 2009-06-03 16:59:37 UTC
Created attachment 346430 [details]
Output to '/var/log/messages' during initiation and failure.

Comment 2 Bug Zapper 2009-06-09 17:02:51 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 3 August Schwerdfeger 2009-09-16 16:17:31 UTC
The problem appears to be related to the use of the 802.11n protocol, as the connection works normally when I disable 802.11n by inserting the following line into /etc/modprobe.d/local.conf:

options iwlagn 11n_disable=1 11n_disable50=1

Comment 4 John Heidemann 2009-11-19 20:12:24 UTC
I was able to reproduce this problem under Fedora 12:
On an Lenovo X200s,
where the iwlagn driver is trying to get a 
Intel Wireless WiFi Link 5100AGN REV=0x54
to talk to a WPA2 network (basically the same as the description).

Also, I can confirm the work-around in #3 does work-around the problem,
at the cost of losing 802.11n.

Comment 5 Dan Williams 2009-11-29 22:14:38 UTC
-> kernel and this is a driver issue, not a supplicant issue.

Please try latest 2.6.30.9 kernels available in F11 updates.  It's quite possible they will fix the issue.  If not, please make sure you check the "I'm providing the requested information" checkbox to move the bug out of NEEDINFO state.

Comment 6 August Schwerdfeger 2009-12-01 21:11:11 UTC
Using kernel version 2.6.30.9-99.fc11.x86_64, the connection still fails when 802.11n is turned on but works normally when 802.11n is turned off.

Comment 7 wojnilowicz 2010-02-02 11:09:59 UTC
(In reply to comment #0)
 
> When I connect to a certain WPA2-Enterprise network using an Intel 5100AGN
> wireless adapter (iwlagn driver), the connection is successfully made, but
> after only a few seconds ceases to function. This does not appear to register
> with NetworkManager as a dropped connection.

I also experienced this when signal strenght was ca. 42 % but I was able to surf internet for at least 2 minutes. I reconnected and Internet returned.

Now I'm writing from place where signal strength is ca. 65% and I'm not losing connection since at least 10 minutes.

Additional info:
1) the same wireless card
2) Fedora 12 Kernel 2.6.31.12-174.2.3 i686.PAE
3)
iwl5000-firmware-8.24.2.12-2
wpa_supplicant-1:0.6.8-8
NetworkManager-1:0.7.997-2.git20091214
4) I connect using WPA2-Enterprise TLS with CA certificate (.pem) and Private key(.p12)
5) I didn't set 
options iwlagn 11n_disable=1 11n_disable50=1

Comment 8 John W. Linville 2010-03-10 15:03:03 UTC
Just curious, can you replicate with a 2.6.32-based kernel?

F-11 -- http://koji.fedoraproject.org/koji/buildinfo?buildID=158901

F-12 -- http://koji.fedoraproject.org/koji/buildinfo?buildID=158902

Comment 9 John Heidemann 2010-03-10 15:23:13 UTC
I will try with current F12 when I can (maybe as long as next week).

Comment 10 John Heidemann 2010-03-15 17:06:12 UTC
Tried with 2.6.32.9-70.fc12.x86_64.
I see the same problem as the original report (connection drops "after a while") when connection to an 802.11abgn router.
When I put "options iwlagn 11n_disable=1 11n_disable50=1" in /etc/modprobe.d/local/conf things seem happier.

Comment 11 Stanislaw Gruszka 2010-03-16 15:15:19 UTC
August, John, 

Can You try a new kernel 2.6.32.10 from koji, which contains a N-only network fix, perhaps this fix helps also with that issue.

If bug is not fixed, please provide logs when module is loaded with debug=0x47833fff parameter. This will generate a lots of debugging messages.

When logging, please assure you have "kern.*" log to messages in /etc/rsyslog.conf like in example bellow:

*.info;kern.*;mail.none;authpriv.none;cron.none                /var/log/messages

If you will modify /etc/rsyslog.conf please do not forgot to restart syslog daemon.

Test of rawhide 2.6.34 kernel, will be also very much appreciated, as we would know if the bug is fixed upstream or not.

Comment 12 Stanislaw Gruszka 2010-04-02 12:46:58 UTC
Hi John

(In reply to comment #10)
> Tried with 2.6.32.9-70.fc12.x86_64.
> I see the same problem as the original report (connection drops "after a
> while") when connection to an 802.11abgn router.

What about kernel from here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=164636

Comment 13 John Heidemann 2010-04-09 21:26:46 UTC
I pulled down that kernel from koji, but it demands kernel-firmware >= 2.6.32.10-94.fc12 to install (and that will be necessary to test wireless).  

Can I just ignore that rpm dependency?  I don't see kernel-firmware in koji.  (Although perhaps I'm not searching correctly?)

Comment 14 Stanislaw Gruszka 2010-04-12 07:36:04 UTC
kernel-firmware is available to download on above koji page as noarch package.

If you have kernel-firmware package installed from older 2.6.32.x kernel you can use --nodeps.

Comment 15 John Heidemann 2010-04-14 00:17:42 UTC
Sigh, in the time it too me to test koji, there was a new official kernel that supercedes 2.6.32.10-94.

I'm running the released 2.6.32.11-99.fc12.x86_64, and, hey, it seems to work.  That is, iwconfig reports:

wlan0     IEEE 802.11abgn  ESSID:"xxx"  
          Mode:Managed  Frequency:2.417 GHz  Access Point: 00:11:92:01:A6:70   
          Bit Rate=1 Mb/s   Tx-Power=15 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=53/70  Signal level=-57 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

So I've been locked in to an n-base station all day, without the fix mentioned in comment #10.  So potentially the bug got fixed between 2.6.32.10-90 and 2.6.32.11-99!

I'll post again if I notice problems after more extensive testing.  (I've primarily been on ethernet, not wireless.)  But potentially this one is closable as fixed.

Comment 16 Stanislaw Gruszka 2010-04-15 12:19:28 UTC
Ok, I'm closing this bug. Please reopen if You get this issue again.

Comment 17 Harry Smith 2010-04-23 17:34:40 UTC
Ok, I am having a similar problem as above.  If I boot with the 2.6.32.11-99.fc12.i686.PAE  the system stalls.  I receive the IP address then dead but does not disconnect. 
If I boot with the 2.6.31.5-127.fc12.i686.PAE kernel everything works fine.  I am using an AirLink 101 PCMCIA which is a straight G card and a Linksys WRT54GL Firmware Version: v4.30.11.  Wireless security is set to wpa2-psk, aes, group rekey 3600.

Comment 18 Stanislaw Gruszka 2010-04-26 10:58:19 UTC
Hi Harry 

AirLink 101 is different device, so this is different bug. Please open new bug report for it and assign it to me. Thanks.

Comment 19 August Schwerdfeger 2010-06-09 19:22:33 UTC
I just got a chance to test this again with Fedora 13 (kernel-2.6.33.5-112.fc13.x86_64). It is still not working.

I unfortunately did not have enough time to collect logs with the debug option enabled; if they are needed, notify me within the next two weeks.

Comment 20 John Heidemann 2010-06-09 19:44:21 UTC
This Works For Me on F13, consistent with comment #15 (which was against F12).
(Kernel: 2.6.33.5-112.fc13.x86_64)

Comment 21 Stanislaw Gruszka 2010-06-10 07:51:31 UTC
Reopening. 

August, what is your AP model?

Comment 22 August Schwerdfeger 2010-06-10 16:37:18 UTC
It is a semi-public access point and I do not know the model name. Is there a way to determine this remotely?

Comment 23 Stanislaw Gruszka 2010-06-17 20:19:21 UTC
No as far a I know. We can only see what AP send to us like beacon frames or other types of frames. 

Could you please try new kernel from koji:
http://koji.fedoraproject.org/koji/buildinfo?buildID=178268

We have some fixes applied that may help with this bug. If it not helps, logs will be needed.

Comment 24 August Schwerdfeger 2010-09-06 03:09:00 UTC
I was hoping to get back to that AP at some point to make the tests (I am now working in a different location), but that now looks impossible. If the problem crops up with another AP I will see if I can post some logs.

Comment 25 Stanislaw Gruszka 2010-09-06 06:47:07 UTC
Ok, I'm closing the bug with insufficient data resolution.


Note You need to log in before you can comment on or make changes to this bug.