# iwlwifi not ready for N?

## bornmw

Hi

I've got two pieces of hardware (laptop and foxconn barebone) and both of them have Centrino Wireless-N 1000:

02:00.0 Network controller: Intel Corporation Centrino Wireless-N 1000

	Subsystem: Intel Corporation Centrino Wireless-N 1000 BGN

	Flags: bus master, fast devsel, latency 0, IRQ 44

	Memory at f2400000 (64-bit, non-prefetchable) [size=8K]

	Capabilities: [c8] Power Management version 3

	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+

	Capabilities: [e0] Express Endpoint, MSI 00

	Capabilities: [100] Advanced Error Reporting

	Capabilities: [140] Device Serial Number 00-26-c7-ff-ff-34-XX-XX

	Kernel driver in use: iwlwifi

	Kernel modules: iwlwifi

---

04:00.0 Network controller: Intel Corporation Centrino Wireless-N 1000

	Subsystem: Intel Corporation Centrino Wireless-N 1000 BGN

	Flags: bus master, fast devsel, latency 0, IRQ 46

	Memory at fe900000 (64-bit, non-prefetchable) [size=8K]

	Capabilities: [c8] Power Management version 3

	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+

	Capabilities: [e0] Express Endpoint, MSI 00

	Capabilities: [100] Advanced Error Reporting

	Capabilities: [140] Device Serial Number 74-e5-0b-ff-ff-b6-XX-XX

	Kernel driver in use: iwlwifi

The first one connects to N network, but after suspend/resume TCP stops working (I can arping but I can't ping or use any other services).

The second one connects to N network but TCP doesn't work from the beginning (and arp is just fine).

When doing rmmod iwlwifi ; modprobe iwlwifi 11n_disable=1 everything starts to work - G speed is at its max.

My router is a good one and windows doesn't have any problems connecting to it at N speeds.

Does anyone have the same problems with iwlwifi, or just have it working? Is there any way to make it work with N speeds?

Thanks

----------

## Gusar

Try the LTS kernel (3.0.x). iwlwifi issues with N in the current kernels is a known thing.

----------

## bornmw

and is there any bug related to this issue that I could subscribe to and get notification once it's fixed?  :Smile: 

----------

## cach0rr0

 *bornmw wrote:*   

> and is there any bug related to this issue that I could subscribe to and get notification once it's fixed? 

 

i cant comment on that as i dont know any bug numbers offhand

but with wireless the bugs are too numerous to get useful feedback IMHO. This particular bug (whatever's affecting you here) may be fixed, and 10 more new ones introduced. 

As to your original question, for a long while i had my AP running in BGN mode

maybe 2 weeks ago i set it to N-only, and it's been a bit more stable

I am using similar hardware, and whenever i find a kernel that seems to behave nicely with wireless, i may stick with it for 3, 4, 6 months. If I try a new kernel, i keep the "safe" one around in case the new one upchucks on wireless

```

02:00.0 Network controller: Intel Corporation Centrino Wireless-N 1000

        Subsystem: Intel Corporation Centrino Wireless-N 1000 BGN

        Flags: bus master, fast devsel, latency 0, IRQ 47

        Memory at d8500000 (64-bit, non-prefetchable) [size=8K]

        Capabilities: [c8] Power Management version 3

        Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+

        Capabilities: [e0] Express Endpoint, MSI 00

        Capabilities: [100] Advanced Error Reporting

        Capabilities: [140] Device Serial Number 00-1e-64-ff-ff-2b-90-38

        Kernel driver in use: iwlwifi

        Kernel modules: iwlwifi

```

I too, used 11n_disable=1 for a long while. I dropped it around 3.2, and started running in N mode

I don't get much better than G speeds however

further info, FWIW

```

hplaptop ~ # iwconfig wlan0

wlan0     IEEE 802.11bgn  ESSID:"FBI Surveillance Van 3"  

          Mode:Managed  Frequency:2.457 GHz  Access Point: 68:7F:74:64:95:4E   

          Bit Rate=58.5 Mb/s   Tx-Power=14 dBm   

          Retry  long limit:7   RTS thr:off   Fragment thr:off

          Encryption key:off

          Power Management:off

          Link Quality=65/70  Signal level=-45 dBm  

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:9599  Invalid misc:2654   Missed beacon:0

hplaptop ~ # uname -a

Linux hplaptop.whitehathouston.com 3.3.4-gentoo #1 SMP PREEMPT Tue Jun 19 23:46:36 CDT 2012 x86_64 Intel(R) Core(TM)2 Duo CPU T6600 @ 2.20GHz GenuineIntel GNU/Linux

```

connection is not perfect, but it is stable enough im not pulling my hair out. Maybe once every 36 hours it steps on its dick, so i stop wicd, rmmod iwlwifi,mac80211,cfg80211, sleep for 15, modprobe iwlwifi, sleep 15, start wicd, and things go back to normal. 

My AP is a Links WRT410N, running DD-WRT.

----------

## bornmw

Thanks for that very useful info!

I will definitely try to switch to N-only this w/e.

But unfortunately I don't have this option to restart iwlwifi module every once in a while b/c one of WiFi consumers is my Linux media center - it's mostly used when I'm not home.

Will keep an eye on kernel updates and iwlwifi.

----------

## bornmw

That's a miracle - switching to N only solved all my wireless issues!

Now both devices work just fine.

Thanks!!!

----------

## bornmw

 *bornmw wrote:*   

> Now both devices work just fine.

 

except for the actual file transfer speed  :Smile: 

----------

## cach0rr0

in case this is of any interest - 

3.6.0 is so far more or less stable for me.

previously, my "use it, and dont screw with it!" kernel was 3.3.4 (gentoo-sources on both)

only problems with 3.6 so far, signal strength doesnt seem to be as good as it was, but that could just as easily be a result of kernel devs fixing how they calculate signal strength. I don't think that's the case, though - my metric is basically, with 3.3.4 i could bring my laptop into the crapper and wireless was ok, on 3.6.0 i bring the laptop to the crapper and cant get signal. 

...actually, as i type this...I'm betting it's because unlike all of my other kernels, i really rushed configuring this one, and left CONFIG_CFG80211_DEFAULT_PS=y, when i know fully well power saving crap causes issues. 

so yeah, so far all good on 3.6.

----------

## hephooey

One thing I noticed about 3.6 kernel is 5ghz_disable option of the iwlwifi module is no longer effective, the flag is still there but it does nothing, I am not sure they removed the code delibrately or it just got lost when the code was reorganized, adding it back it trivial, but it did caught me in surprise when I first upgrade.

----------

## bornmw

So I'm getting around 15mbps stable with N only between two linux boxes (via good router) each on 3.6.6:

```
wlan0     IEEE 802.11bgn  ESSID:"XXXX"  

          Mode:Managed  Frequency:2.462 GHz  Access Point: C8:60:00:94:07:52   

          Bit Rate:72.2 Mb/s   Tx-Power=14 dBm   

          Retry  long limit:7   RTS thr:off   Fragment thr:off

          Encryption key:off

          Power Management:off

          Link Quality=61/70  Signal level=-49 dBm  

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:520122  Invalid misc:138   Missed beacon:0
```

Any luck getting better results?

----------

## cach0rr0

 *bornmw wrote:*   

> So I'm getting around 15mbps stable with N only between two linux boxes (via good router) each on 3.6.6:
> 
> Any luck getting better results?

 

i generally get between 14.4Mbit and 18.4Mbit 

this is less than my downstream pipe, so I haven't been too fussed. 

Somewhere in the 3.6 series (i think 3.6.2) I've stumbled upon a new bug that makes the wireless unusable. 

So in my case, currently, it's my driver going titsup - nothing an rmmod + modprobe doesn't sort, but annoying nonetheless. 

Every few hours, one of these:

```

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

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

[267559.380966] ------------[ cut here ]------------

[267559.380977] WARNING: at drivers/net/wireless/iwlwifi/dvm/tx.c:1187 iwlagn_rx_reply_tx+0x7d6/0x7f0 [iwldvm]()

[267559.380979] Hardware name: HP Pavilion dv4 Notebook PC

[267559.380980] Modules linked in: iwldvm mac80211 iwlwifi cfg80211 rfkill ac battery snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec led_class snd_pcm snd_page_alloc snd_timer snd soundcore psmouse [last unloaded: rfkill]

[267559.380996] Pid: 0, comm: swapper/1 Tainted: G        W    3.6.5-gentoo #1

[267559.380998] Call Trace:

[267559.380999]  <IRQ>  [<ffffffff810666ab>] ? warn_slowpath_common+0x7b/0xc0

[267559.381010]  [<ffffffffa00217e6>] ? iwlagn_rx_reply_tx+0x7d6/0x7f0 [iwldvm]

[267559.381016]  [<ffffffffa019c271>] ? iwl_irq_tasklet+0x501/0x8a0 [iwlwifi]

[267559.381020]  [<ffffffff8106d61a>] ? tasklet_action+0x5a/0xc0

[267559.381023]  [<ffffffff810bb6ee>] ? handle_irq_event_percpu+0x7e/0x140

[267559.381026]  [<ffffffff8106dc88>] ? __do_softirq+0xa8/0x150

[267559.381030]  [<ffffffff8157932c>] ? call_softirq+0x1c/0x30

[267559.381034]  [<ffffffff8100422d>] ? do_softirq+0x4d/0x80

[267559.381036]  [<ffffffff8106e035>] ? irq_exit+0x75/0x80

[267559.381039]  [<ffffffff81003d6c>] ? do_IRQ+0x5c/0xd0

[267559.381041]  [<ffffffff815779a7>] ? common_interrupt+0x67/0x67

[267559.381042]  <EOI>  [<ffffffff813472f7>] ? acpi_idle_enter_bm+0x240/0x277

[267559.381048]  [<ffffffff813472f2>] ? acpi_idle_enter_bm+0x23b/0x277

[267559.381052]  [<ffffffff81461339>] ? cpuidle_idle_call+0x89/0x100

[267559.381055]  [<ffffffff8100b49f>] ? cpu_idle+0x5f/0xc0

[267559.381057] ---[ end trace 6f0cc2483ea0ca3e ]---

[267559.403489] cfg80211: Calling CRDA to update world regulatory domain

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

[267561.887293] wlan0: authenticate with 68:7f:74:64:95:4e

[267561.897803] wlan0: send auth to 68:7f:74:64:95:4e (try 1/3)

[267561.899652] wlan0: authenticated

[267561.900176] wlan0: associate with 68:7f:74:64:95:4e (try 1/3)

[267561.904497] wlan0: RX AssocResp from 68:7f:74:64:95:4e (capab=0x431 status=0 aid=1)

[267561.913271] wlan0: associated

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

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

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

```

it will continue this cycle (fail to flush all tx fifo queues, followed by the crash, followed by fail to flush all tx fifo queues) in perpetuity until i remove the driver, and reload it. 

fun stuff. this is just life with linux wireless as ive come to know, love, and hate.

----------

## khayyam

cach0rr0 ... have you tried the following?

```
# modprobe iwlwifi bt_coex_active=0
```

I think the issue may be this bug ... read from comment #61.

HTH & best ... khay

----------

## cach0rr0

 *khayyam wrote:*   

> cach0rr0 ... have you tried the following?
> 
> ```
> # modprobe iwlwifi bt_coex_active=0
> ```
> ...

 

yip, found that one. no dice. 

also tried wd_disable=1

and tried the two in conjunction (which is how ive been running it as of late)

issue still pops up. interesting to me when i found that bug, there is nothing bluetooth whatsoever on this machine - bluetooth hardware simply does not exist. 

I've just learned to live with it, and accepted it as part of life with linux wireless. Intel seems to screw something up pretty much every release that makes for unstable connectivity. In other words, intel firmware sucks. One of my Atheros rigs had similar issues a while back. Just sorta grinning and bearing it.

----------

## kimmie

FYI everyone, I have had same experience as cach0rr0 with breakage, then fixage, then breakage, although for me currently things are working perfectly with:

options iwlwifi auto_agg=0 wd_disable=1

3.4.x kernel

Intel Centrino Ultimate-N 6300

Setting auto_agg=0 seems to be what fixes up suspend/resume issues.

----------

## cach0rr0

 *kimmie wrote:*   

> FYI everyone, I have had same experience as cach0rr0 with breakage, then fixage, then breakage, although for me currently things are working perfectly with:
> 
> options iwlwifi auto_agg=0 wd_disable=1
> 
> 3.4.x kernel
> ...

 

ta, might try that. I don't use suspend/resume at all, and this does sometimes happen when im using the damn thing normally

but i can just about always rely on this popping up if i put the laptop down for a few hours

so it's at least worth a shot. Doesn't cost anything extra to try it...

----------

## CkoTuHa

Just so that you guys know, you are not alone(props to MJ): https://bugzilla.kernel.org/show_bug.cgi?id=48921

----------

## cach0rr0

saw that one too  :Laughing: 

yeah iwlwifi is just a bit of a mess

I don't use NM, and stopped using wicd actually. 

I just have things set in /etc/conf.d/net (and then wpa_supplicant.conf). Saves me a bit of headache when i have to do the usual restarts/rmmod's

after getting enough hits for this particular bug, and having gotten numerous hits for bugs in the past, enough reading and the very scientific conclusion is "iwlwifi microcode sucks". That, and, "if they fix something in the kernel iwlwifi stack, expect it to break something else". Worth noting there hasn't been an iwl-1000 ucode release since April 2011. 

I just grin and bear it, because the alternative is having to reboot into Windows, and be perpetually miserable

----------

## kimmie

Interesting... that bug report talks about tx queue stalling... that's what I saw, but always a short time after a message saying that auto-aggregation had been turned on. This happened consistently immediately after a resume, but also at other times. After I set auto_agg=0, the problem went away.

----------

## bornmw

The nightmare is over. Finally ditched that N-1000 ^&* and got Atheros AR928X, had to remove ThinkPad whitelist to do that.

Connection speed instantly jumped to 130Mbs without any tuning, I hope to be able to do 300Mbs, but that's for another thread now   :Laughing: 

----------

