Difference between revisions of "ThinkPad 11a/b/g/n Wireless LAN Mini Express Adapter"

From ThinkWiki
Jump to: navigation, search
(AP dropout with madwifi)
(changed categorization)
 
(27 intermediate revisions by 3 users not shown)
Line 2: Line 2:
 
|style="vertical-align:top" |
 
|style="vertical-align:top" |
 
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#F8F8FF; align:right">
 
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#F8F8FF; align:right">
=== ThinkPad 11a/b/g/n Wireless LAN Mini Express Adapter ===
+
This is a WiFi Adapter that is installed in a Mini-PCI Express slot IBM/Lenovo partnumber 42T0825 [http://www-307.ibm.com/pc/support/site.wss/MIGR-64222.html]
This is a WiFi Adapter that is installed in a Mini-PCI Express slot IBM partnumber 42T0825 [http://www-307.ibm.com/pc/support/site.wss/MIGR-64222.html]
 
  
=== Features ===
+
= Features =
 
* Chipset: Atheros AR5418/AR5008
 
* Chipset: Atheros AR5418/AR5008
 
* Integrated Mac Processor and Radio Chip: Atheros, unknown model
 
* Integrated Mac Processor and Radio Chip: Atheros, unknown model
Line 15: Line 14:
 
|}
 
|}
  
=== Identification ===
+
= Identification =
 
To determine the chipset your card uses, issue the following commands:  
 
To determine the chipset your card uses, issue the following commands:  
  
Line 23: Line 22:
  
 
If you get something different than above despite having the most current PCI IDs, please report it here!
 
If you get something different than above despite having the most current PCI IDs, please report it here!
 +
=ath9k=
 +
There is now active development of a free driver [[ath9k]] that aims to fully support the draft 11n protocol. It is available in the mainline linux kernel starting with 2.6.27 and therefore automatically included in any distribution running this kernel (eg. Ubuntu Intrepid Ibex). The version in this latest kernel however does not support "aggregation" which basically means you will only see a slight increase in speed from the 11g protocol (mesured as 25 Mb/s vs 20Mb/s). If your distribution does not yet include this kernel (aheghm Debian), you'll have to [[How to install the development version of atk9k|jump through a few hoops]].
  
=== Linux WiFi driver ===
+
=madwifi=
 
+
Madwifi is a native linux driver that used to use a binary-only HAL and so must be compiled separately from the kernel. The HAL has recently been opened up, however with the development of ath9k mentioned above, the future of this project in particular with regard to this chipset is uncertain. It does not support the draft 11n protocol, but will work in "legacy" 11g mode. Support for this chipset was initially planned for release 0.9.4, but this inclusion had to be [http://www.madwifi.org/wiki/Releases/0.9.4#Announcement postponed] as a critical update with a bug fix for compilation with the 2.6.24 kernel was necessary before the pre-release trunk was sufficiently stable. Thus, it is still necessary to download the prerelease snapshot from trunk using subversion.
For native Linux support, the "madwifi" driver can be used. Here's the latest word regarding work on supporting the ar5008/ar5418 chipset:
 
 
 
*  milestone changed from version 0.9.x - progressive release candidate phase to version 0.9.4.
 
  FYI: the madwifi-hal-0.9.30.13 branch has been merged to trunk
 
(and the branch has been removed). If you don't want to wait until the next release (v0.9.4),  
 
you could go with a snapshot or checkout from trunk - just make sure that your code is >= r2360.
 
  
 
There is a [[How_to_checkout_and_install_madwifi_experimental_driver_for_ar5008 | howto]], which describes the procedure for getting the snapshot to work.
 
There is a [[How_to_checkout_and_install_madwifi_experimental_driver_for_ar5008 | howto]], which describes the procedure for getting the snapshot to work.
Line 38: Line 33:
  
 
There is an new ticket for this card at [http://madwifi.org/ticket/1243 madwifi-branch, #1243].
 
There is an new ticket for this card at [http://madwifi.org/ticket/1243 madwifi-branch, #1243].
 +
<nowiki>Insert non-formatted text here</nowiki>
  
=== Using the Windows Driver in Linux ===
+
= Using the Windows Driver in Linux =
  
 
If you have a weak stomach for pre-release software, you can always use "ndiswrapper" (>= 1.29) to wrap the [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-66449 Windows driver] supplied by Lenovo. This isn't as bad as you think. It does work like a charm, but you may have problems if you're using a 64 bit kernel since it's not clear that a 64 bit windows XP driver exists (ndiswrapper currently doesn't support Vista drivers). Here's the [[How_to_install_ndiswrapper_for_the_ThinkPad_11a/b/g/n_Wireless_LAN_Mini_Express_Adapter | Howto]].
 
If you have a weak stomach for pre-release software, you can always use "ndiswrapper" (>= 1.29) to wrap the [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-66449 Windows driver] supplied by Lenovo. This isn't as bad as you think. It does work like a charm, but you may have problems if you're using a 64 bit kernel since it's not clear that a 64 bit windows XP driver exists (ndiswrapper currently doesn't support Vista drivers). Here's the [[How_to_install_ndiswrapper_for_the_ThinkPad_11a/b/g/n_Wireless_LAN_Mini_Express_Adapter | Howto]].
  
===Problems/Bugs?===
+
=Problems/Bugs?=
====[http://en.wikipedia.org/wiki/Non-maskable_interrupt Non-Maskable Interrupt] with madwifi====
+
==[http://en.wikipedia.org/wiki/Non-maskable_interrupt Non-Maskable Interrupt] with madwifi==
 +
{{NOTE|This problem appears to be more or less fixed with recent subversion snapshots. If you are still experiencing this, try upgrading to the latest version.}}
 +
 
 
A number of folks have reported getting errors while using the experimental madwifi driver with the AR5418. After hours of flawless operation, the Kernel sometimes throws an NMI after which, the wifi dies. Aside from rebooting, suspending (to ram or disk) and resuming seems to be the only method to recover.
 
A number of folks have reported getting errors while using the experimental madwifi driver with the AR5418. After hours of flawless operation, the Kernel sometimes throws an NMI after which, the wifi dies. Aside from rebooting, suspending (to ram or disk) and resuming seems to be the only method to recover.
  
Line 66: Line 64:
 
[http://sourceforge.net/mailarchive/forum.php?thread_name=20070809145900.GD16023%40hank.org&forum_name=madwifi-users]
 
[http://sourceforge.net/mailarchive/forum.php?thread_name=20070809145900.GD16023%40hank.org&forum_name=madwifi-users]
  
{{HINT|There's a [http://madwifi.org/ticket/1017 ticket on madwifi] with some discussion and suggestions for the rx FIFO overrun problem. To summarise, issuing the command <tt>iwpriv wlan0 bgscan 0</tt> '''may''' be a preventative measure.}}
+
{{HINT|There's a [http://madwifi.org/ticket/1017 ticket on madwifi] with some discussion and suggestions for the rx FIFO overrun problem.}}
 
 
====AP dropout with madwifi====
 
You may experience randomly disconnections from the AP when using the madwifi driver ([http://madwifi.org/ticket/1004 madwifi ticket 1004]). It seems to be loosely correlated with how busy the AP is (or possibly how much interference is present). This would appear to be a beacon miss problem (the AP is too busy to acknowledge the existence of your station at regular enough intervals) which can be confirmed by running
 
{{cmdroot|echo 0xc80000 > /proc/sys/net/<device>/debug}}
 
and then
 
{{cmduser|dmesg}}
 
right after you have been disconnected. If it says something about a beacon miss, you might see an improvement by upgrading to the most recent subversion of the driver. It appears that there has been significant improvement on this problem.
 
  
There is also a recently added private ioctl which controls how many beacon misses (or alternatively how many beaconless milliseconds) the card will tolerate before dropping the connection and trying to reassociate. You can confirm that your version of the driver has this feature by running
+
A '''possible''' preventitive measure is issuing the command
{{cmduser|/sbin/iwpriv -a 2>/dev/null  | grep bmiss}}. Which should give output that looks something like
+
{{cmdroot|iwpriv <device> bgscan 0}}
 +
each time you load the driver. To make this change "permanent", you could add this command to your distribution's ifup networking scripts as described below.
 +
===Debian===
 +
Open up {{path|/etc/network/interfaces}} in a text editor and find the entry for your wireless device. Which should look something like
 
<pre>
 
<pre>
wlan0    get_bmiss_ms:20480 
+
iface wlan0 inet manual
wlan0     get_bmiss:200
+
     wpa-driver madwifi
 +
     wpa-roam  /etc/network/wpa_supplicant.conf
 
</pre>
 
</pre>
The numbers in the above output are rather high compared to the built in defaults, but it is probably better to have them too high than too low seeing as how reassociation is far from an instantaneous process and you probably don't need a fast dissociation reflex unless you see a significant performance improvement upon reassocation. To set these values use
+
and add the line
{{cmdroot|iwpriv <device> bmiss <#of misses>}} or
 
{{cmdroot|iwpriv <device> bmiss_ms <#of ms of misses allowed>}}
 
 
 
====No Draft n support in Linux (madwifi '''and''' ndiswrapper)====
 
Once you have your shiny new wireless card working, you can give yourself a pat on the back for a job well done. However, if your are a perfectionist and enough of a sucker to go for a pricey draft n router, your job is not done. Well actually maybe it is and mayhap you shouldn't go for that router either. Though the card can indeed be made to work under Linux, it is not clear if it will operate under the draft n protocol.
 
 
 
Tests with the DLink DIR-655, which has the same AR5008 chipset family, proved discouraging. The first test using the windows driver natively in windows does indeed work. The connection should be listed as 300Mbit/s and should connect in the router's "802.11ng only" mode. Not having access to any linux benchmarking tools, there was only ssh which gave transfer speeds of ~3.5MByte/s. Not exactly the 10x as promised by the box even when accounting for ssh overhead, but a decent improvement to 11g speeds.
 
 
 
As for Linux, things get a little dicey. Using no authentication/encryption, wpa_supplicant (with -D wext) and the ndiswrapper driver, the card is only able to connect if the router is set to "802.11g only" mode. In "Mixed 802.11ng, 802.11g and 802.11b" mode, there is only a brief period of connectivity where no ip address is assigned and then the connection is dropped. In "802.11ng only" mode, no connection at all.
 
 
 
Though it does appear that there are some out there looking at 11n for the new ath5k open-hal branch of madwifi which has yet to support this chip at all[http://kerneltrap.org/mailarchive/linux-ath5k-devel/2007/10/27/362513], [http://madwifi.org/ticket/1636 this ticket] does not bode well for the current trunk madwifi driver. Indeed, using the madwifi driver (and giving wpa_supplicant  either the -D madwifi or -D wext option) is more promising, but the result is still the same: no 11n connection. Using the router's "Mixed 802.11ng, 802.11g and 802.11b" mode does work, but only provides (admittedly solid) 11g speeds of 20*10^6bits/sec using the TCP_STREAM benchmark in the netperf suite. Again, however "802.11ng only" mode doesn't work. A connection seems to happen and will sit there for some time while no ip address is assigned even by invoking dhclient manually.
 
 
 
The kernel message upon probing the madwifi ath_pci module shows no 11n rates message with corresponding 300Mbps confirming that such capabilities are not within the scope of the driver.
 
 
 
 
<pre>
 
<pre>
$modprobe ath_pci
+
    post-up iwpriv wlan0 bgscan 0
$dmesg
 
.
 
.
 
.
 
[28696.420000] ath_hal: 0.9.30.13 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133)
 
[28696.430000] wlan: 0.8.4.2 (svn r2708)
 
[28696.430000] ath_pci: 0.9.4.5 (svn r2708)
 
[28696.430000] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 21
 
[28696.430000] PCI: Setting latency timer of device 0000:03:00.0 to 64
 
[28696.570000] ath_pci: switching rfkill capability off
 
[28696.580000] ath_rate_sample: 1.2 (svn r2708)
 
[28696.580000] ath_pci: switching per-packet transmit power control off
 
[28696.580000] wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
 
[28696.580000] wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
 
[28696.580000] wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
 
[28696.580000] wifi0: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
 
[28696.580000] wifi0: turboG rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
 
[28696.580000] wifi0: H/W encryption support: WEP AES AES_CCM TKIP
 
[28696.580000] wifi0: mac 12.10 phy 8.1 radio 12.0
 
[28696.580000] wifi0: Use hw queue 1 for WME_AC_BE traffic
 
[28696.580000] wifi0: Use hw queue 0 for WME_AC_BK traffic
 
[28696.580000] wifi0: Use hw queue 2 for WME_AC_VI traffic
 
[28696.580000] wifi0: Use hw queue 3 for WME_AC_VO traffic
 
[28696.580000] wifi0: Use hw queue 8 for CAB traffic
 
[28696.580000] wifi0: Use hw queue 9 for beacons
 
[28696.580000] wifi0: Atheros 5418: mem=0xedf00000, irq=21
 
[28696.590000] udev: renamed network interface ath0 to wlan0
 
 
</pre>
 
</pre>
 +
to the end of it where of course you substitute your interface name (e.g., "ath0") for "wlan0".
  
=== Hardware switch ===
+
= Hardware switch =
 
 
Some ThinkPads have a hardware switch that must be in the '''on''' position for the radio to work, regardless of driver state:
 
  
[[Image:Wireless-switch.png|(ThinkPad R60 radio switch in the ON position)]]
+
{{Note_wlan_hardware_switch}}
  
 
In addition to hard-switching the wireless card, the switch also generates an [[Acpid|acpi event]] on transition from hi->lo and vice versa. It is however the same event in both directions.
 
In addition to hard-switching the wireless card, the switch also generates an [[Acpid|acpi event]] on transition from hi->lo and vice versa. It is however the same event in both directions.
  
=== ThinkPads this card may be found in ===
+
= ThinkPads this card may be found in =
 
* {{R60}}, {{R60e}}
 
* {{R60}}, {{R60e}}
 
* {{T60}}, {{T60p}}
 
* {{T60}}, {{T60p}}
Line 147: Line 100:
 
* [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-66449 Windows driver at Lenovo]
 
* [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-66449 Windows driver at Lenovo]
  
[[Category:Components]]
+
[[Category:WLAN Adapters]]

Latest revision as of 12:26, 16 November 2020

This is a WiFi Adapter that is installed in a Mini-PCI Express slot IBM/Lenovo partnumber 42T0825 [1]

Features

  • Chipset: Atheros AR5418/AR5008
  • Integrated Mac Processor and Radio Chip: Atheros, unknown model
  • IEEE Standards: 802.11a, 802.11b, 802.11g, 802.11n (draft)
  • PCI ID: 168c:0024

 

Identification

To determine the chipset your card uses, issue the following commands:

# update-pciids
# lspci | egrep -i 'network|atheros|wireless'
03:00.0 Network controller: Atheros Communications, Inc. AR5418 802.11a/b/g/n Wireless PCI Express Adapter (rev 01)

If you get something different than above despite having the most current PCI IDs, please report it here!

ath9k

There is now active development of a free driver ath9k that aims to fully support the draft 11n protocol. It is available in the mainline linux kernel starting with 2.6.27 and therefore automatically included in any distribution running this kernel (eg. Ubuntu Intrepid Ibex). The version in this latest kernel however does not support "aggregation" which basically means you will only see a slight increase in speed from the 11g protocol (mesured as 25 Mb/s vs 20Mb/s). If your distribution does not yet include this kernel (aheghm Debian), you'll have to jump through a few hoops.

madwifi

Madwifi is a native linux driver that used to use a binary-only HAL and so must be compiled separately from the kernel. The HAL has recently been opened up, however with the development of ath9k mentioned above, the future of this project in particular with regard to this chipset is uncertain. It does not support the draft 11n protocol, but will work in "legacy" 11g mode. Support for this chipset was initially planned for release 0.9.4, but this inclusion had to be postponed as a critical update with a bug fix for compilation with the 2.6.24 kernel was necessary before the pre-release trunk was sufficiently stable. Thus, it is still necessary to download the prerelease snapshot from trunk using subversion.

There is a howto, which describes the procedure for getting the snapshot to work.

There is an old ticket for this card at madwifi, #1001.

There is an new ticket for this card at madwifi-branch, #1243. Insert non-formatted text here

Using the Windows Driver in Linux

If you have a weak stomach for pre-release software, you can always use "ndiswrapper" (>= 1.29) to wrap the Windows driver supplied by Lenovo. This isn't as bad as you think. It does work like a charm, but you may have problems if you're using a 64 bit kernel since it's not clear that a 64 bit windows XP driver exists (ndiswrapper currently doesn't support Vista drivers). Here's the Howto.

Problems/Bugs?

Non-Maskable Interrupt with madwifi

NOTE!
This problem appears to be more or less fixed with recent subversion snapshots. If you are still experiencing this, try upgrading to the latest version.

A number of folks have reported getting errors while using the experimental madwifi driver with the AR5418. After hours of flawless operation, the Kernel sometimes throws an NMI after which, the wifi dies. Aside from rebooting, suspending (to ram or disk) and resuming seems to be the only method to recover.

Uhhuh. NMI received for unknown reason b0 on CPU 0.
You have some hardware problem, likely on the PCI bus.
Dazed and confused, but trying to continue
wifi0: rx FIFO overrun; resetting
wifi0: rx FIFO overrun; resetting
wifi0: rx FIFO overrun; resetting

See the following threads and bug reports: [2] [3] [4] [5] [6]

Hint:
There's a ticket on madwifi with some discussion and suggestions for the rx FIFO overrun problem.

A possible preventitive measure is issuing the command # iwpriv <device> bgscan 0 each time you load the driver. To make this change "permanent", you could add this command to your distribution's ifup networking scripts as described below.

Debian

Open up /etc/network/interfaces in a text editor and find the entry for your wireless device. Which should look something like

iface wlan0 inet manual
    wpa-driver madwifi
    wpa-roam   /etc/network/wpa_supplicant.conf

and add the line

    post-up iwpriv wlan0 bgscan 0

to the end of it where of course you substitute your interface name (e.g., "ath0") for "wlan0".

Hardware switch

NOTE!
ThinkPad R60 radio switch in the ON position
Some ThinkPads have a hardware switch that must be in the on position for the radio to work, regardless of driver state.

In addition to hard-switching the wireless card, the switch also generates an acpi event on transition from hi->lo and vice versa. It is however the same event in both directions.

ThinkPads this card may be found in

Related Links