December 2014
M T W T F S S
« Mar    
1234567
891011121314
15161718192021
22232425262728
293031  
18

Refs

Categories

Archives

profile for slm on Stack Exchange, a network of free, community-driven Q&A sites

Debugging an Intermittently Dropping Intel Wireless-N 1000 Network Card on Fedora 14

Background

Recently I’ve been experiencing a strange problem with my wireless NIC on my Lenovo/Thinkpad T410i laptop. The laptop would invariably stop being able to access the network. I would get a connection to our wireless access point (even an IP address), but wasn’t able to do much else. Pinging other systems or anything else would simply hang. lshw showed the NIC card to be an Intel Centrino Wireless-N 1000 card.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
% lshw -c network
...
...
 *-network
       description: Wireless interface
       product: Centrino Wireless-N 1000
       vendor: Intel Corporation
       physical id: 0
       bus info: pci@0000:03:00.0
       logical name: wlan0
       version: 00
       serial: 00:44:c7:12:f0:ba
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=iwlagn driverversion=2.6.35.12-88.fc14.x86_64 firmware=128.50.3.1 build 13488 ip=192.168.1.20 latency=0 link=yes multicast=yes wireless=IEEE 802.11bgn
       resources: irq:47 memory:f2400000-f2401fff

My problem only appeared while using the laptop at my day job where there are a LOT of other WiFi networks. Here’s my diagnoses of the problem.

Debugging & Sluething

For starters, when the network would stop working I had limited success in restarting NetworkManager and/or rebooting the laptop completely. To date the problem has occurred a handful of times, and in several cases the full reboot wasn’t even able to get the NIC card working again. In those cases I either resorted to using the ethernet jack or I called it a day and just went home 8-). Looking at the dmesg log I saw a lot of messages that looked suspious around the wireless NIC:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
% dmesg
...
...
[  129.111606] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  129.278240] padlock: VIA PadLock not detected.
[  133.162493] iwlagn 0000:03:00.0: iwlagn_tx_agg_start on ra = 00:44:c7:12:f0:ba tid = 0
[  139.134446] iwlagn 0000:03:00.0: Fail finding valid aggregation tid: 6
[  139.625259] wlan0: no IPv6 routers present
[  148.159410] iwlagn 0000:03:00.0: iwlagn_tx_agg_start on ra = 00:44:c7:12:f0:ba tid = 6
[  149.398720] lo: Disabled Privacy Extensions
[  156.700117] iwlagn 0000:03:00.0: Fail finding valid aggregation tid: 0
[  168.314511] iwlagn 0000:03:00.0: iwlagn_tx_agg_start on ra = 00:44:c7:12:f0:ba tid = 0
[  186.599610] iwlagn 0000:03:00.0: Fail finding valid aggregation tid: 0
[  189.644342] iwlagn 0000:03:00.0: iwlagn_tx_agg_start on ra = 00:44:c7:12:f0:ba tid = 0
[  209.035584] iwlagn 0000:03:00.0: Fail finding valid aggregation tid: 6
[  216.989012] iwlagn 0000:03:00.0: Fail finding valid aggregation tid: 6
[  237.742329] iwlagn 0000:03:00.0: Fail finding valid aggregation tid: 0
[  252.295339] iwlagn 0000:03:00.0: Fail finding valid aggregation tid: 0
[  276.355600] iwlagn 0000:03:00.0: iwlagn_tx_agg_start on ra = 00:44:c7:12:f0:ba tid = 0
[  308.826502] iwlagn 0000:03:00.0: Fail finding valid aggregation tid: 6
[  327.469032] iwlagn 0000:03:00.0: iwlagn_tx_agg_start on ra = 00:44:c7:12:f0:ba tid = 0
[  357.808657] wlan0: deauthenticating from 00:44:c7:12:f0:ba by local choice (reason=3)
[  357.822562] cfg80211: Calling CRDA to update world regulatory domain
[  357.822589] cfg80211: Calling CRDA for country: US
[  357.830270] cfg80211: Regulatory domain changed to country: US
[  357.830274]     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[  357.830276]     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[  357.830279]     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[  357.830281]     (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[  357.830284]     (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[  357.830286]     (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[  357.830288]     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
[  369.842771] wlan0: deauthenticating from 00:90:7f:85:be:9f by local choice (reason=3)
[  369.855010] wlan0: authenticate with 00:90:7f:85:be:9f (try 1)
[  369.859943] wlan0: authenticated
[  369.860001] wlan0: associate with 00:90:7f:85:be:9f (try 1)
[  369.864683] wlan0: RX AssocResp from 00:90:7f:85:be:9f (capab=0x411 status=0 aid=2)
[  369.864689] wlan0: associated

So I started googling a bit and found a few leads.

This thread looked promising:

Specifically comments #89 & #96. These particular commenters seemed to think that it was something to do with the version of wpa_supplicant. So I went to the Fedora Project’s Koji Buildsystem and found the lastest SRPM from Fedora 15. It was up to version 0.7.3 Release 6.fc15, where as on Fedora 14, I was still back on version 0.6.8 Release 10.fc14.

NOTE: Here’s the complete list of wpa_supplicant packages available @ the Koji Buildsystem.

Potential Solution #1?

After downloading the fc15 RPM I changed its name to fc14 and rebuilt it.

1
2
3
4
5
6
7
8
9
10
11
% mv wpa_supplicant-0.7.3-6.fc15.src.rpm wpa_supplicant-0.7.3-6.fc14.src.rpm
% rpmbuild --rebuild wpa_supplicant-0.7.3-6.fc14.src.rpm 
...
...
Wrote: /home/saml/rpmbuild/RPMS/x86_64/wpa_supplicant-0.7.3-6.fc14.x86_64.rpm
Wrote: /home/saml/rpmbuild/RPMS/x86_64/wpa_supplicant-gui-0.7.3-6.fc14.x86_64.rpm
Wrote: /home/saml/rpmbuild/RPMS/x86_64/libeap-0.7.3-6.fc14.x86_64.rpm
Wrote: /home/saml/rpmbuild/RPMS/x86_64/libeap-devel-0.7.3-6.fc14.x86_64.rpm
Wrote: /home/saml/rpmbuild/RPMS/x86_64/wpa_supplicant-debuginfo-0.7.3-6.fc14.x86_64.rpm
...
...

The only package that’s relavent is this one, wpa_supplicant-0.7.3-6.fc14.x86_64.rpm, so I installed it.

1
2
3
% sudo rpm -Uvh /home/saml/rpmbuild/RPMS/x86_64/wpa_supplicant-0.7.3-6.fc14.x86_64.rpm
Preparing...                ########################################### [100%]
   1:wpa_supplicant         ########################################### [100%]

NOTE: You can download the SRPM and the resulting RPMs from my yum repo.

Fix #1 Verdict?

So after letting this change bake for the rest of the week it didn’t seem to solve my WiFi woes. Here’s what the dmesg log looked like with the newer version of wpa_supplicant, if you’re curious:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
% dmesg
....
....
[15931.421441] wlan0: deauthenticating from 00:09:5b:ab:f4:12 by local choice (reason=3)
[15931.460841] cfg80211: Calling CRDA to update world regulatory domain
[15931.460887] cfg80211: Calling CRDA for country: US
[15931.470056] cfg80211: Regulatory domain changed to country: US
[15931.470059]     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[15931.470062]     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[15931.470064]     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[15931.470067]     (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[15931.470069]     (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[15931.470072]     (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[15931.470074]     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
[15944.743596] e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
[15944.793924] e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
[15944.796103] ADDRCONF(NETDEV_UP): eth0: link is not ready
[15944.836379] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[15944.958722] wlan0: deauthenticating from 00:09:5b:ab:f4:12 by local choice (reason=3)
[15944.995551] wlan0: authenticate with 00:09:5b:ab:f4:12 (try 1)
[15944.998028] wlan0: authenticated
[15944.998083] wlan0: associate with 00:09:5b:ab:f4:12 (try 1)
[15945.000865] wlan0: RX AssocResp from 00:09:5b:ab:f4:12 (capab=0x431 status=0 aid=1)
[15945.000871] wlan0: associated
[15945.005250] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

After a day or two I noticed more messages like the following in dmesg:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
% dmesg
....
....
[118114.470353] iwlagn 0000:03:00.0: Microcode SW error detected.  Restarting 0x2000000.
[118114.470362] iwlagn 0000:03:00.0: Loaded firmware version: 128.50.3.1 build 13488
[118114.470382] iwlagn 0000:03:00.0: Start IWL Error Log Dump:
[118114.470387] iwlagn 0000:03:00.0: Status: 0x000212E4, count: 5
[118114.470548] iwlagn 0000:03:00.0: Desc                               Time       data1      data2      line
[118114.470553] iwlagn 0000:03:00.0: SYSASSERT                    (#05) 0076316678 0x00020084 0x00000835 2101
[118114.470557] iwlagn 0000:03:00.0: pc      blink1  blink2  ilink1  ilink2  hcmd
[118114.470561] iwlagn 0000:03:00.0: 0x0D1B4 0x0E5B6 0x0E5B6 0x00892 0x00000 0x230001C
[118114.470565] iwlagn 0000:03:00.0: CSR values:
[118114.470568] iwlagn 0000:03:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
[118114.470575] iwlagn 0000:03:00.0:        CSR_HW_IF_CONFIG_REG: 0X00c80300
[118114.470582] iwlagn 0000:03:00.0:          CSR_INT_COALESCING: 0X0000ff40
[118114.470589] iwlagn 0000:03:00.0:                     CSR_INT: 0X00000000
[118114.470595] iwlagn 0000:03:00.0:                CSR_INT_MASK: 0X00000000
[118114.470602] iwlagn 0000:03:00.0:           CSR_FH_INT_STATUS: 0X00000000
[118114.470608] iwlagn 0000:03:00.0:                 CSR_GPIO_IN: 0X00000000
[118114.470614] iwlagn 0000:03:00.0:                   CSR_RESET: 0X00000000
[118114.470621] iwlagn 0000:03:00.0:                CSR_GP_CNTRL: 0X080403c5
[118114.470628] iwlagn 0000:03:00.0:                  CSR_HW_REV: 0X0000006c
[118114.470634] iwlagn 0000:03:00.0:              CSR_EEPROM_REG: 0X007a08e5
[118114.470641] iwlagn 0000:03:00.0:               CSR_EEPROM_GP: 0X90000001
[118114.470647] iwlagn 0000:03:00.0:              CSR_OTP_GP_REG: 0X00010001
[118114.470654] iwlagn 0000:03:00.0:                 CSR_GIO_REG: 0X00080046
[118114.470660] iwlagn 0000:03:00.0:            CSR_GP_UCODE_REG: 0X000036c1
[118114.470667] iwlagn 0000:03:00.0:           CSR_GP_DRIVER_REG: 0X00000000
[118114.470673] iwlagn 0000:03:00.0:           CSR_UCODE_DRV_GP1: 0X00000000
[118114.470680] iwlagn 0000:03:00.0:           CSR_UCODE_DRV_GP2: 0X00000000
[118114.470686] iwlagn 0000:03:00.0:                 CSR_LED_REG: 0X00000058
[118114.470693] iwlagn 0000:03:00.0:        CSR_DRAM_INT_TBL_REG: 0X88023f44
[118114.470699] iwlagn 0000:03:00.0:        CSR_GIO_CHICKEN_BITS: 0X27800200
[118114.470706] iwlagn 0000:03:00.0:             CSR_ANA_PLL_CFG: 0X00880300
[118114.470712] iwlagn 0000:03:00.0:           CSR_HW_REV_WA_REG: 0X0001001a
[118114.470719] iwlagn 0000:03:00.0:        CSR_DBG_HPET_MEM_REG: 0Xffff0000
[118114.470722] iwlagn 0000:03:00.0: FH register values:
[118114.470739] iwlagn 0000:03:00.0:         FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X1306dc00
[118114.470756] iwlagn 0000:03:00.0:        FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X01306890
[118114.470772] iwlagn 0000:03:00.0:                  FH_RSCSR_CHNL0_WPTR: 0X00000010
[118114.470788] iwlagn 0000:03:00.0:         FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
[118114.470805] iwlagn 0000:03:00.0:          FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
[118114.470821] iwlagn 0000:03:00.0:            FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
[118114.470838] iwlagn 0000:03:00.0:    FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
[118114.470854] iwlagn 0000:03:00.0:                FH_TSSR_TX_STATUS_REG: 0X07ff0001
[118114.470871] iwlagn 0000:03:00.0:                 FH_TSSR_TX_ERROR_REG: 0X00000000
[118114.470931] iwlagn 0000:03:00.0: Start IWL Event Log Dump: nothing in log

Potential Solution #2?

Came across this tip on the ThinkWiki site. The claim is that there’s a potential firmware bug that sometimes drops connections. 2 workarounds are to:

  1. remove the iwlagn kernel module (rmmod iwlagn) and re-add it (modprobe iwlagn)
  2. add a driver option to disable 802.11n support.

The first workaround is pretty self explanatory, the 2nd, you can do one off like this:

1
% modprobe iwlagn 11n_disable=1

NOTE: You can do this permanently via the /etc/modprobe.d directory by adding a file like so:

1
2
# /etc/modprobe.d/wireless.conf
options iwlagn 11n_disable=1

The file can be called anything, I simply chose wireless.conf just because. This linux kernel bugzilla ticket #16691 seems to be the issue. After making the above changes to the driver’s options I activated them by unloading/loading the iwlagn kernel module.

1
2
3
4
5
# unload
% rmmod iwlagn
 
# load
% modprobe iwlagn

Fix #2 Verdict?

This fix seems to have resolved my issue. I’m not thrilled with the wholesale disabling of 802.11n support but I can live with it for the short term, assuming this issue gets resolved in an upcoming kernel release. Interestingly I still get the iwlagn and/or Intel firmware dumping an error log out to dmesg but it doesn’t appear to be effecting performance of my wireless NIC thus far.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
% dmesg
....
....
[84618.727621] iwlagn 0000:03:00.0: Desc                               Time       data1      data2      line
[84618.727627] iwlagn 0000:03:00.0: SYSASSERT                    (#05) 3783742691 0x00020084 0x00000835 2101
[84618.727630] iwlagn 0000:03:00.0: pc      blink1  blink2  ilink1  ilink2  hcmd
[84618.727635] iwlagn 0000:03:00.0: 0x0D1B4 0x0E5B6 0x0E5B6 0x00892 0x00000 0x2D6001C
[84618.727638] iwlagn 0000:03:00.0: CSR values:
[84618.727641] iwlagn 0000:03:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
[84618.727648] iwlagn 0000:03:00.0:        CSR_HW_IF_CONFIG_REG: 0X00c80300
[84618.727655] iwlagn 0000:03:00.0:          CSR_INT_COALESCING: 0X00000040
[84618.727661] iwlagn 0000:03:00.0:                     CSR_INT: 0X00000000
[84618.727667] iwlagn 0000:03:00.0:                CSR_INT_MASK: 0X00000000
[84618.727674] iwlagn 0000:03:00.0:           CSR_FH_INT_STATUS: 0X00000000
[84618.727679] iwlagn 0000:03:00.0:                 CSR_GPIO_IN: 0X00000000
[84618.727686] iwlagn 0000:03:00.0:                   CSR_RESET: 0X00000000
[84618.727692] iwlagn 0000:03:00.0:                CSR_GP_CNTRL: 0X080403c5
[84618.727698] iwlagn 0000:03:00.0:                  CSR_HW_REV: 0X0000006c
[84618.727705] iwlagn 0000:03:00.0:              CSR_EEPROM_REG: 0X007a08e5
[84618.727711] iwlagn 0000:03:00.0:               CSR_EEPROM_GP: 0X90000001
[84618.727717] iwlagn 0000:03:00.0:              CSR_OTP_GP_REG: 0X00010001
[84618.727724] iwlagn 0000:03:00.0:                 CSR_GIO_REG: 0X00080046
[84618.727730] iwlagn 0000:03:00.0:            CSR_GP_UCODE_REG: 0X000068b4
[84618.727736] iwlagn 0000:03:00.0:           CSR_GP_DRIVER_REG: 0X00000000
[84618.727742] iwlagn 0000:03:00.0:           CSR_UCODE_DRV_GP1: 0X00000000
[84618.727748] iwlagn 0000:03:00.0:           CSR_UCODE_DRV_GP2: 0X00000000
[84618.727755] iwlagn 0000:03:00.0:                 CSR_LED_REG: 0X00000058
[84618.727761] iwlagn 0000:03:00.0:        CSR_DRAM_INT_TBL_REG: 0X881322e0
[84618.727767] iwlagn 0000:03:00.0:        CSR_GIO_CHICKEN_BITS: 0X27800200
[84618.727774] iwlagn 0000:03:00.0:             CSR_ANA_PLL_CFG: 0X00880300
[84618.727780] iwlagn 0000:03:00.0:           CSR_HW_REV_WA_REG: 0X0001001a
[84618.727786] iwlagn 0000:03:00.0:        CSR_DBG_HPET_MEM_REG: 0Xffff0000
[84618.727790] iwlagn 0000:03:00.0: FH register values:
[84618.727806] iwlagn 0000:03:00.0:         FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X130ca600
[84618.727822] iwlagn 0000:03:00.0:        FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X0130c980
[84618.727839] iwlagn 0000:03:00.0:                  FH_RSCSR_CHNL0_WPTR: 0X000000b8
[84618.727855] iwlagn 0000:03:00.0:         FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
[84618.727871] iwlagn 0000:03:00.0:          FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
[84618.727887] iwlagn 0000:03:00.0:            FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
[84618.727904] iwlagn 0000:03:00.0:    FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
[84618.727920] iwlagn 0000:03:00.0:                FH_TSSR_TX_STATUS_REG: 0X07ff0001
[84618.727936] iwlagn 0000:03:00.0:                 FH_TSSR_TX_ERROR_REG: 0X00000000
[84618.727996] iwlagn 0000:03:00.0: Start IWL Event Log Dump: nothing in log
[87701.522611] npviewer.bin[3543]: segfault at 98fe130 ip 00000000098fe130 sp 00000000ff86691c error 15
[97359.029068] iwlagn 0000:03:00.0: Microcode SW error detected.  Restarting 0x82000000.
[97359.029080] iwlagn 0000:03:00.0: Loaded firmware version: 128.50.3.1 build 13488
[97359.029097] iwlagn 0000:03:00.0: Start IWL Error Log Dump:
[97359.029100] iwlagn 0000:03:00.0: Status: 0x000212E4, count: 5
....
....

In a couple of weeks/months I’ll revisit this to see if anything has changed with either the Intel wireless NIC driver or the kernel.

8 comments to Debugging an Intermittently Dropping Intel Wireless-N 1000 Network Card on Fedora 14

  • Alex

    Thanks for this post! I was having this problem and did not know how to disable 802.11g. After twiddling with the options of the module I can finally use my network again. Thanks!

  • Luis

    Hi there,

    I’ve just received my $1200 Lenovo Thinkpad T420i with Intel Centrino Wireless N1000 and I have experienced similar problem. The difference is that I could barely ping to other machine. It was slow as hell, I would say impossible to open a website. I thought that it would be fixed with F15 but there it is. So, I wanted to try with another distro. Ubuntu was the lucky one and surprise! It works fine, no problems at all! So I am unfortunately working on Ubuntu instead of using my loved Fedora.
    I tried to disable 802.11g but it did not work for me. Same issues. I hope it will be fixed very very soon.
    Do you guys have news about that? Anything new?

    • I’ve been using my Thinkpad T410 for over a month with 802.11N disabled as I mentioned in this post and it’s been working pretty flawlessly. Did you try and disable 802.11N as I described in the post? I would imagine you’re experiencing the same problem that I was with my Thinkpad. I’m running Fedora 14 still. I have not seen any updates etc. that would fix the issues with the intel driver so that it works with 802.11N enabled. Can you see what drivers/configurations Ubuntu has around your Wireless-N 1000 NIC?

  • md-tech

    I rcvd Dell with Intel Centrino 1000 wireless adapter. I along with tech support could not understand why either would not connect or would connect then drop. Found that the adapter requires the router to be set on channel 11 rather than auto.

  • stauc

    just disable bluetooth

    • I would but I don’t have that on my laptop so the issue doesn’t have anything to do with Bluetooth.

      This problem seems to be 802.11N specific. I have a Thinkpad T410 and a co-worker recently (July 2012) got a W530 with the Intel Centrino wireless-N 2200 and he’s also having the same issues. He’s running Windows 7, I’m running Fedora 14, so it doesn’t seem to be any particular issue with the OS & drivers. NOTE: we’re both running the latest Intel drivers as of Sept. 2012.

      It seems to be an issue with specific laptop vendor’s implementation/integration of the Intel wireless NICs and wireless access points from our own experimenting.

      To date we’ve run into this problem with the following laptops:

      Dell laptops
      • - various ones using Intel wireless-N NICs
      3 different Thinkpads
      • - T410 w/ Centrino Wireless-N 1000 (Fedora 14)
      • - L530 w/ Centrino Wireless-N 2100 (Windows 7 64b w/ latest Intel drivers)
      • - W530 w/ Centrino Wireless-N 2200 (Windows 7 64b w/ latest Intel drivers)

      We’ve also had other laptops with wireless-N NICs work just fine (for eg. Macbook Airs), so as I said, it’s definitely a issue with particular combinations of laptops and wireless access points.

  • Javier

    Very useful.
    Thanks for sharing this!

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>