wifi disconnects randomly when using N connection

[Laura Czajkowski]

I have difficultly connecting to wifi and the only way around this is to
* rmmod iwlwifi
* modprobe iwlwifi

If i disconnect or restart the wifi I need to do the above again to get back working

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: linux-image-3.8.0-6-generic 3.8.0-6.13
ProcVersionSignature: Ubuntu 3.8.0-6.13-generic 3.8.0-rc7
Uname: Linux 3.8.0-6-generic x86_64
ApportVersion: 2.8-0ubuntu4
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: czajkowski 2087 F.... pulseaudio
CRDA:
 country GB:
  (2402 - 2482 @ 40), (N/A, 20)
  (5170 - 5250 @ 40), (N/A, 20)
  (5250 - 5330 @ 40), (N/A, 20), DFS
  (5490 - 5710 @ 40), (N/A, 27), DFS
Date: Fri Feb 15 18:06:47 2013
HibernationDevice: RESUME=UUID=39ffc27c-0543-4453-912b-36884a1b6f4c
InstallationDate: Installed on 2011-12-26 (417 days ago)
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
MachineType: TOSHIBA SATELLITE Z830
MarkForUpload: True
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.8.0-6-generic root=UUID=ce6ea08d-b7a1-41cb-9678-b534afddd7e8 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.8.0-6-generic N/A
 linux-backports-modules-3.8.0-6-generic N/A
 linux-firmware 1.102
SourcePackage: linux
UpgradeStatus: Upgraded to raring on 2013-02-10 (4 days ago)
dmi.bios.date: 07/31/2012
dmi.bios.vendor: TOSHIBA
dmi.bios.version: Version 1.70
dmi.board.asset.tag: 0000000000
dmi.board.name: Portable PC
dmi.board.vendor: TOSHIBA
dmi.board.version: Version A0
dmi.chassis.asset.tag: 0000000000
dmi.chassis.type: 10
dmi.chassis.vendor: TOSHIBA
dmi.chassis.version: Version 1.0
dmi.modalias: dmi:bvnTOSHIBA:bvrVersion1.70:bd07/31/2012:svnTOSHIBA:pnSATELLITEZ830:pvrPT22LE-00F004EN:rvnTOSHIBA:rnPortablePC:rvrVersionA0:cvnTOSHIBA:ct10:cvrVersion1.0:
dmi.product.name: SATELLITE Z830
dmi.product.version: PT22LE-00F004EN
dmi.sys.vendor: TOSHIBA

[Laura Czajkowski (czajkowski)]

Attaching as per sforshee request.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Seth Forshee (sforshee)]

I tried to reproduce this over the weekend with no luck. What follows are notes from looking at the logs, for my own benefit.

You're on a network with multiple APs and seem to be roaming between them a lot. Just before you start experiencing problems network-manager says "disconnecting for new activation request," which afacit means that you manually told network-manager to reconnect (at least it's trying to connect to a different AP the same network). At that point the association proceeds until the 4-way handshake to establish the keys, which times out. Shortly thereafter iwlwifi starts emitting these errors:

  iwlwifi 0000:02:00.0: fail to flush all tx fifo queues

After that the 4-way handshake fails a couple of times, with the AP sending a deauth frame with reason code 2 (previous authentication no longer valid). Then it looks like iwlwifi gets reloaded and things go back to normal.

[Seth Forshee (sforshee)]

I think what would help most now is to collect a trace of mac80211 and iwlwifi when this problem happens. This might be a bit tricky since the trace will potentially collect a lot of data and it sounds like the problem isn't deterministic. You may want to restart the trace periodically while you aren't seeing the issue to keep the trace from growing too large.

To start tracing, install the trace-cmd package and run the following commands:

 $ echo 32768 | sudo tee /sys/kernel/debug/tracing/buffer_size_kb
 $ sudo trace-cmd record -e mac80211 -e mac80211_msg -e iwlwifi -e iwlwifi_msg

The second command will run until you press Ctrl+C. To restart trace collection just kill trace-cmd and restart it.

You'll need to start tracing in a terminal and leave it running while the issue happens. Afterward, kill trace-cmd, and you will have a trace.dat file in whatever directory you ran trace-cmd from. Compress trace.dat and capture dmesg, then either attach them here or put them somwhere where I can get at them.

Thanks!

[Laura Czajkowski (czajkowski)]

Attaching dmesg as requested.

[Laura Czajkowski (czajkowski)]

I've run the trace, the wifi wasn't working well. I let it run for a while then restarted the drivers and let the trace run. When I did this no issue occurred.

[Seth Forshee (sforshee)]

Did wifi disconnect? I don't see that in either the trace or dmesg. Can you describe what kind of problems you were having? I haven't found anything in dmesg or in the trace yet that's an obvious indication of a problem.

[Laura Czajkowski (czajkowski)]

I've run it all morning while Iw as working.

It is connected to the wifi, but it is seems to lose many many packets, pages times out, lags on irc.

this is my 5th attempt to get this comment uploaded.

[Seth Forshee (sforshee)]

There's still nothing obviously wrong that shows up in the trace. I'll look more closely.

In the mean time, I'd like you to try a couple things to see whether or not they produce a more reliable connection. Please try these individually, not in combination.

First, load iwlwifi with the argument 11n_disable=1, and connect to the same network that you're experiencing problems with.

Second, after connecting to the network run 'sudo iw wlan0 set power_save off'. I note in your trace that the wireless is in powersave mode much of the time, so I'm curious whether disabling it makes any difference.

[Seth Forshee (sforshee)]

Looking at the traces some more, there are only a couple of things I can find that looks even remotely problematic. The first are BA session timeouts for transmit, but it's as likely as not that these just represent periods of relatively low network activity.

The other is "release an RX reorder frame due to timeout on earlier frames" messages. These would be a result of failing to receive expected data frames. There are a fairly good number of these, but I'm not convinced that it's happening frequently enough to account for the issues you've described. The errors do tend to be batched but are still only lasting for a few milliseconds.

Both of these are related specifically to 802.11n, so I still think the tests in comment #10 are appropriate.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Juan Jose Amor Iglesias (jjamor)]

Just verified that, disabling 11n the connection become stable.

I've added "options iwlwifi 11n_disable=1" to a file /etc/modprobe.d/personal-opts.conf