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
Created attachment 410623 [details] var log messages
Let me know if I can provide anything else!
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?
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.
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.
Another update... this is happening without the VPN connection as well.
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!
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.
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.
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.
Cradlepoint MBR1000, Firmware 1.6.9 Hope this helps!
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.
Ok, over to kernel then. Can you grab the output of 'uname -a' for us too? Thanks!
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
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...
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?
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
Closing based on comment 17...