Bug 587825 - [iwlagn] 802.11n causes connection failures
[iwlagn] 802.11n causes connection failures
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
i386 Linux
low Severity high
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-30 20:22 EDT by Chris Morgan
Modified: 2010-06-18 11:08 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-18 11:08:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg.out (90.94 KB, application/octet-stream)
2010-04-30 20:22 EDT, Chris Morgan
no flags Details
var log messages (2.95 MB, text/plain)
2010-04-30 20:27 EDT, Chris Morgan
no flags Details
var log messages 050810 (1.01 MB, text/plain)
2010-05-08 16:10 EDT, Chris Morgan
no flags Details

  None (edit)
Description Chris Morgan 2010-04-30 20:22:55 EDT
Created attachment 410619 [details]
dmesg.out

Description of problem:

Bug 478686 asked to open this if seen with F12.  I am seeing the following over and over in my log:
Apr 30 20:10:08 localhost NetworkManager: <info> (wlan0): supplicant connection state:  scanning -> disconnected
Apr 30 20:10:08 localhost NetworkManager: <info> (wlan0): supplicant connection state:  disconnected -> associating
Apr 30 20:10:08 localhost NetworkManager: <info> (wlan0): supplicant connection state:  associating -> associated
Apr 30 20:10:08 localhost NetworkManager: <info> (wlan0): supplicant connection state:  associated -> 4-way handshake
Apr 30 20:10:08 localhost NetworkManager: <info> (wlan0): supplicant connection state:  4-way handshake -> group handshake
Apr 30 20:10:08 localhost NetworkManager: <info> (wlan0): supplicant connection state:  group handshake -> completed

The NetworkManager does not show any disconnect, but make no mistake, nothing works until I reset the network with a stop/start.

Version-Release number of selected component (if applicable):
NetworkManager-openvpn-0.7.996-4.git20090923.fc12.i686
NetworkManager-glib-0.8.0-6.git20100408.fc12.i686
NetworkManager-0.8.0-6.git20100408.fc12.i686
NetworkManager-vpnc-0.7.996-4.git20090921.fc12.i686
NetworkManager-pptp-0.7.997-3.git20100120.fc12.i686
NetworkManager-gnome-0.8.0-6.git20100408.fc12.i686


How reproducible:
Just use the network for an extended period.  At first, I thought avahi-daemon may be causing it, so I disabled it, but I get the same problem.

Steps to Reproduce:
1.
2.
3.
  
Actual results:
Have to reset network

Expected results:
Not to constantly reset network and have VPN work.

Additional info:
dmesg output and /var/log/messages attached
Comment 1 Chris Morgan 2010-04-30 20:27:58 EDT
Created attachment 410623 [details]
var log messages
Comment 2 Chris Morgan 2010-04-30 20:28:27 EDT
Let me know if I can provide anything else!
Comment 3 Dan Williams 2010-05-03 04:11:34 EDT
Note that state changes from completed -> handshake -> completed are normal; that's the WPA rekeying happening which is essential to WPA security.

Is your AP 802.11 capable and do you have 802.11n turned on at the AP?

When the problem occurs, can you try to ping the AP from a terminal and report the results?
Comment 4 Chris Morgan 2010-05-08 15:01:14 EDT
Sorry for the delay in response, I have been out of the country.  I just looked at my AP and it is set to allow b/g/n, so yes "n" is turned on.  When the freeze occurs, I cannot ping anything even though networkmanager is showing me as connected, I'm guessing that I'm really not.

I tried the following:
1.  Opening a new browser and going to my AP (192.168.0.1), and it does not connect.
2.  Opening a terminal and pinging 192.168.0.1 and it does not work.

Again, networkmanager shows me as connected.  Additionally, the problem really only arises, it seems, when I use the Red Hat VPN (using vpnc).  I'll stay connected for a bit, and then the entire connection (not just the VPN) will exhibit the behavior.
Comment 5 Chris Morgan 2010-05-08 16:10:44 EDT
Created attachment 412570 [details]
var log messages 050810

This is /var/log/messages.  I was connected to the VPN when the freeze occurs.  I tried connecting to my AP when the freeze happens.  I have to reset NetworkManager in order to get connected.  I did it twice within an hour or so.
Comment 6 Chris Morgan 2010-05-09 01:04:23 EDT
Another update... this is happening without the VPN connection as well.
Comment 7 Chris Morgan 2010-05-09 18:34:22 EDT
OK, it is reaching the point of being ridiculous :).  Based on the inquiry you made of me, I changed my router to b-only to see if it makes a difference, but many of my devices in my home are n.  Nothing new in /var/log/messages outside of a ton of the supplicant messages.

I have also verified that the problem is occurring with and without the VPN, so it's likely not related.  Hope this information helps!

Again, based on what you asked of me, when the "freeze" occurs where it still looks like I am connected, I cannot ping or connect to 192.168.0.1, which is my AP.  I'm running a Lenovo x200 with the built-in wireless card -- let me know how else to assist.  Thanks!
Comment 8 Dan Williams 2010-05-10 18:06:22 EDT
Try the following to isolate the issue to the driver:

rmmod iwlagn
modprobe iwlagn 11n_disable50=1 11n_disable=1

which will tell the driver to disable the 802.11n functionality on your laptop only.  See how stable the connection is over a period of a day or so.  You'll have to repeat that each time you restart your machine, though there are ways of making that configuration more permanent.
Comment 9 Chris Morgan 2010-05-10 18:14:24 EDT
I reloaded the driver with the mentioned parameters.  I'm travelling the next couple of days, but I'll watch it closely at the end of the week and report the results this weekend.

I also set my AP back to mixed b/g/n.  Moving it to "g-only" was good to me, and I no longer had the freeze issue.  Not sure if that data helps or not.
Comment 10 Dan Williams 2010-05-12 14:46:08 EDT
Yes, setting the AP to g-only and having the problem go away may well indicate a driver problem with 802.11n.

What model of AP do you  have, and what firmware version is the AP running?  That often helps the kernel wifi team.
Comment 11 Chris Morgan 2010-05-12 16:15:12 EDT
Cradlepoint MBR1000, Firmware 1.6.9

Hope this helps!
Comment 12 Chris Morgan 2010-05-13 19:49:45 EDT
Just some more data for you guys.  I have my AP set to b/g/n again, and I've disable n on my laptop.  I'm having no problems, so whatever is going on with the "n code" for my Fedora build is the likely culprit.
Comment 13 Dan Williams 2010-05-14 12:17:42 EDT
Ok, over to kernel then.  Can you grab the output of 'uname -a' for us too?  Thanks!
Comment 14 Chris Morgan 2010-05-14 13:33:07 EDT
Happy to do it, Dan... Linux cmorgan 2.6.32.11-99.fc12.i686.PAE #1 SMP Mon Apr 5 16:15:03 EDT 2010 i686 i686 i386 GNU/Linux
Comment 15 Daniel 2010-05-23 14:14:04 EDT
Hi, i just stumpled over this bugreport searching a solution for the same problem.

Im running Ubuntu 10.04 on a Lenovo T500 but the problem is present since Ubuntu 8.10 (october, 2008) and since then, i had to disable 11n via module-parameter (to make it permanent: echo "options iwlagn 11n_disable=1 11n_disable50=1" > /etc/modprobe.d/wlan.conf)

Im running this kernel (uname -a):
Linux lenmob 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:28:05 UTC 2010 x86_64 GNU/Linux

This is my wlan-nic (lspci):
03:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection

My wlan-router is a "TP-Link WR941N v2" running firmware "3.9.7 Build 090821 Rel.38819n". But over time i did many firmware-updates.

With 11n enabled a "ping -f <ROUTER-IP>" usually provokes a network-breakdown within less than a minute. There is nothing logged in /var/log/syslog about this issue.

Hope, this helps...
Comment 16 John W. Linville 2010-06-09 17:45:02 EDT
It is possible that your device is being incorrectly identified.  Please give this build a try when it completes:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2241530

Does it identify your devices as ABG instead of AGN?
Comment 17 Chris Morgan 2010-06-17 09:09:13 EDT
Hi John,

Sorry for the delay in response.  I am running Fedora 13 now, and the problem seems to have gone away.  As for the device identification, it appears to be correctly identifying the device.

Cheers,
Chris
Comment 18 John W. Linville 2010-06-18 11:08:49 EDT
Closing based on comment 17...

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