Launchpad has imported 19 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=587825.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2010-05-01T00:22:55+00:00 Chris wrote:

Created attachment 410619
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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/0

------------------------------------------------------------------------
On 2010-05-01T00:27:58+00:00 Chris wrote:

Created attachment 410623
var log messages

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/1

------------------------------------------------------------------------
On 2010-05-01T00:28:27+00:00 Chris wrote:

Let me know if I can provide anything else!

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/2

------------------------------------------------------------------------
On 2010-05-03T08:11:34+00:00 Dan wrote:

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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/3

------------------------------------------------------------------------
On 2010-05-08T19:01:14+00:00 Chris wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/4

------------------------------------------------------------------------
On 2010-05-08T20:10:44+00:00 Chris wrote:

Created attachment 412570
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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/5

------------------------------------------------------------------------
On 2010-05-09T05:04:23+00:00 Chris wrote:

Another update... this is happening without the VPN connection as well.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/6

------------------------------------------------------------------------
On 2010-05-09T22:34:22+00:00 Chris wrote:

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!

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/7

------------------------------------------------------------------------
On 2010-05-10T22:06:22+00:00 Dan wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/8

------------------------------------------------------------------------
On 2010-05-10T22:14:24+00:00 Chris wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/9

------------------------------------------------------------------------
On 2010-05-12T18:46:08+00:00 Dan wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/10

------------------------------------------------------------------------
On 2010-05-12T20:15:12+00:00 Chris wrote:

Cradlepoint MBR1000, Firmware 1.6.9

Hope this helps!

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/11

------------------------------------------------------------------------
On 2010-05-13T23:49:45+00:00 Chris wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/12

------------------------------------------------------------------------
On 2010-05-14T16:17:42+00:00 Dan wrote:

Ok, over to kernel then.  Can you grab the output of 'uname -a' for us
too?  Thanks!

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/13

------------------------------------------------------------------------
On 2010-05-14T17:33:07+00:00 Chris wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/14

------------------------------------------------------------------------
On 2010-05-23T18:14:04+00:00 Daniel wrote:

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...

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/15

------------------------------------------------------------------------
On 2010-06-09T21:45:02+00:00 John wrote:

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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/16

------------------------------------------------------------------------
On 2010-06-17T13:09:13+00:00 Chris wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/17

------------------------------------------------------------------------
On 2010-06-18T15:08:49+00:00 John wrote:

Closing based on comment 17...

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/comments/18


** Changed in: linux (Fedora)
       Status: Unknown => Fix Released

** Changed in: linux (Fedora)
   Importance: Unknown => High

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/878800

Title:
  802.11n causes connection failures

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878800/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to