Wireless network configuration

From ArchWiki
Revision as of 16:51, 11 August 2013 by Indigo (talk | contribs) (Troubleshooting: mv of powersaving.)
Jump to: navigation, search

zh-CN:Wireless Setup Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary end Configuring wireless is a two-part process; the first part is to identify and ensure the correct driver for your wireless device is installed (they are available on the installation media, but often have to be installed explicitly), and to configure the interface. The second is choosing a method of managing wireless connections. This article covers both parts, and provides additional links to wireless management tools.

Device driver

The default Arch Linux kernel is modular, meaning many of the drivers for machine hardware reside on the hard drive and are available as modules. At boot, udev takes an inventory of your hardware and loads appropriate modules (drivers) for your corresponding hardware, which will in turn allow creation of a network interface.

Some wireless chipsets also require firmware, in addition to a corresponding driver. Many firmware images are provided by the linux-firmware package which is installed by default, however, proprietary firmware images are not included and have to be installed separately. This is described in #Installing driver/firmware.

  • Udev is not perfect. If the proper module is not loaded by udev on boot, simply load it manually. Note also that udev may occasionally load more than one driver for a device, and the resulting conflict will prevent successful configuration. Be sure to blacklist the unwanted module.
  • The interface name for different drivers and chipsets will vary. Some examples are wlan0, eth1, and ath0. See also Network Configuration#Device names.
Tip: Though not strictly required, it's a good idea to first install user-space tools mentioned in #Manual setup, especially when some problem should appear.

Check the driver status

To check if the driver for your card has been loaded, check the output of lspci -k command. You should see that some kernel driver is in use, for example:

$ lspci -k
06:00.0 Network controller: Intel Corporation WiFi Link 5100
	Subsystem: Intel Corporation WiFi Link 5100 AGN
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi
Note: The internal Wi-Fi card in some laptops may actually be a USB device, so you should check these commands too:
  • lsusb -v
  • dmesg | grep usbcore, you should see something like usbcore: registered new interface driver rtl8187 in the output

Also check the output of ip link command to see if a wireless interface (e.g. wlan0, wlp2s1, ath0) was created. Then bring the interface up with ip link set <interface> up. For example, assuming the interface is wlan0:

# ip link set wlan0 up

If you get this error message: SIOCSIFFLAGS: No such file or directory, it most certainly means your wireless chipset requires a firmware to function.

Check kernel messages for firmware being loaded

$ dmesg |grep firmware
[   7.148259] iwlwifi 0000:02:00.0: loaded firmware version build 35138 op_mode iwldvm

The relevant dmesg output should be prefixed by the module autodetected for the hardware, which can further help in identifying issues.

If the kernel module is successfully loaded and the interface is up, you can skip the next section.

Installing driver/firmware

Check the following lists to discover if your card is supported:

  • The Ubuntu Wiki has a good list of wireless cards and whether or not they are supported either in the Linux kernel or by a user-space driver (includes driver name).
  • Linux Wireless Support and The Linux Questions' Hardware Compatibility List (HCL) also have a good database of kernel-friendly hardware.
  • The kernel page additionally has a matrix of supported hardware.

If your wireless card is listed above, follow the #Troubleshooting drivers and firmware subsection of this page, which contains information about installing drivers and firmware of some specific wireless cards. Then check the driver status again.

If your wireless card is not listed above, it is likely supported only under Windows (some Broadcom, 3com, etc). For these, you can try to use ndiswrapper. See #ndiswrapper for details.

Wireless management

Assuming that your drivers are installed and working properly, you will need to choose a method of managing your wireless connections. The following subsections will help you decide.

Procedure and tools required will depend on several factors:

  • The desired nature of configuration management; from a completely manual command line procedure to an automated solution with graphical front-ends.
  • The encryption type (or lack thereof) which protects the wireless network.
  • The need for network profiles, if the computer will frequently change networks (such as a laptop).
  • Whatever is your choice, you should try to connect using the manual method first. This will help you understand the different steps that are required and troubleshoot possible problems.
  • If possible (e.g. if you manage your Wi-Fi access point), try connecting with no encryption, to check that everything works. Then try using encryption, either WEP (simple to configure, but crackable in a matter of seconds), WPA or WPA2.

The following table shows the different methods that can be used to activate and manage a wireless connection, depending on the encryption and management types, and the various tools that are required. Although there may be other possibilities, these are the most frequently used:

Management method Interface activation Wireless connection management
Assigning IP address
Manually managed,
with no or WEP encryption
ip iw / iwconfig ip / dhcpcd / dhclient
Manually managed,
with WPA or WPA2 PSK encryption
ip iw / iwconfig + wpa_supplicant ip / dhcpcd / dhclient
Automatically managed,
with network profiles support
netctl, Wicd, NetworkManager, etc.

These tools pull in the required dependencies from the list of packages in the manual method.

Manual setup

Just like other network interfaces, the wireless ones are controlled with ip from the iproute2 package. The package wireless_tools then provides a basic set of tools for managing the wireless connection, however, these tools are deprecated in favor of the iw tool. If iw does not work with your card, you can use wireless_tools, the table below gives an overview of comparable commands with both (see [1] for more examples). Additionally, the wpa_supplicant package is required for WPA/WPA2 encryption. These powerful user-space tools work extremely well and allow complete manual control of wireless connection.

  • Examples in this section assume that your wireless device is wlan0 to connect to your_essid wifi accesspoint. Replace both accordingly.
  • Note that most of the commands have to be executed with root permissions. Executed with normal user rights, some of the commands (e.g. iwlist), will exit without error but not produce the correct output either, which can be confusing.
iw command wireless_tools command Description
iw dev wlan0 link iwconfig wlan0 Getting link status.
iw dev wlan0 scan iwlist wlan0 scan Scanning for available access points.
iw wlan0 set type ibss iwconfig wlan0 mode ad-hoc Setting the operation mode to ad-hoc.
iw wlan0 connect your_essid iwconfig wlan0 essid your_essid Connecting to open network.
iw wlan0 connect your_essid 2432 iwconfig wlan0 essid your_essid freq 2432M Connecting to open network specifying channel.
iw wlan0 connect your_essid key 0:your_key iwconfig wlan0 essid your_essid key your_key Connecting to WEP encrypted network using hexadecimal key.
iw wlan0 connect your_essid key 0:your_key iwconfig wlan0 essid your_essid key s:your_key Connecting to WEP encrypted network using ASCII key.
iw dev wlan0 set power_save on iwconfig wlan0 power on Enabling power save.
Note: Depending on your hardware and encryption type, some of these steps may not be necessary. Some cards are known to require interface activation and/or access point scanning before being associated to an access point and being given an IP address. Some experimentation may be required. For instance, WPA/WPA2 users may try to directly activate their wireless network from step #Association.

Getting some useful information

Tip: See official documentation of the iw tool for more examples.
  • First you need to find the name of wireless interface. You can do it with following command:
$ iw dev
	Interface wlan0
		ifindex 3
		wdev 0x1
		addr 12:34:56:78:9a:bc
		type managed
		channel 1 (2412 MHz), width: 40 MHz, center1: 2422 MHz
  • To check link status, use following command. Example output when not connected to an AP:
$ iw dev wlan0 link
Not connected.

When connected to an AP, you will see something like:

$ iw dev wlan0 link
Connected to 12:34:56:78:9a:bc (on wlan0)
	freq: 2412
	RX: 33016518 bytes (152703 packets)
	TX: 2024638 bytes (11477 packets)
	signal: -53 dBm
	tx bitrate: 150.0 MBit/s MCS 7 40MHz short GI

	bss flags:	short-preamble short-slot-time
	dtim period:	1
	beacon int:	100
  • You can get statistic information, such as the amount of tx/rx bytes, signal strength etc., with following command:
$ iw dev wlan0 station dump
Station 12:34:56:78:9a:bc (on wlan0)
	inactive time:	1450 ms
	rx bytes:	24668671
	rx packets:	114373
	tx bytes:	1606991
	tx packets:	8557
	tx retries:	623
	tx failed:	1425
	signal:  	-52 dBm
	signal avg:	-53 dBm
	tx bitrate:	150.0 MBit/s MCS 7 40MHz short GI
	authorized:	yes
	authenticated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no

Interface activation

(Optional, but may be required)

Some cards require that the kernel interface be activated before you can use the iw tool or wireless_tools:

# ip link set wlan0 up
Note: If you get errors like RTNETLINK answers: Operation not possible due to RF-kill, make sure that hardware switch is on. Also, your wireless network card may be soft-blocked. Try getting rfkill and running rfkill list all to check.

Access point discovery

See what access points are available:

# iw dev wlan0 scan | less
Note: If it displays "Interface doesn't support scanning" then you probably forgot to install the firmware. In some cases this message is also displayed when not running iw as root.

The important points to check:

  • ESSID: the "name" of the access point.
  • Quality: in general try something above 40/70.
  • Encryption key: if it is "on", check if you can see any line regarding
    • WEP, WPA, or RSN. Note that RSN and WPA2 are different names for the protocol.
    • Group cipher: value in TKIP, CCMP, both, others.
    • Pairwise ciphers: value in TKIP, CCMP, both, others. Not necessarily the same value than Group cipher.
    • Authentication Suites: value in PSK, 802.1x, others. For home router, you'll usually find PSK (i.e. passphrase). In universities, you are more likely to find 802.1x suite which requires login and password. Then you will need to know which key management is in use (e.g. EAP), and what encapsulation it uses (e.g. PEAP). Find more details at Wikipedia:Authentication protocol and the sub-articles.

Operating mode

(Optional, but may be required)

At this step you might need to set the proper operating mode of the wireless card. More specifically, if you are going to connect an ad-hoc network, you need to set the operating mode to ad-hoc:

# iw wlan0 set type ibss
Note: Changing the operating mode on some cards might require the wireless interface to be down (ip link set wlan0 down).


Depending on the encryption, you need to associate your wireless device with the access point to use and pass the encryption key.

  • No encryption
# iw wlan0 connect your_essid
  • WEP

using a hexadecimal or ASCII key:

# iw wlan0 connect your_essid key 0:your_key

using a hexadecimal or ASCII key, specifying the third set up key as default (keys are counted from zero):

# iw wlan0 connect your_essid key d:2:your_key
  • WPA/WPA2

You need to edit the /etc/wpa_supplicant.conf file as described in WPA_Supplicant and according to what you got from #Access point discovery. Then, issue this command:

# wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf

This is assuming your device uses the wext driver. If this does not work, you may need to adjust these options. If connected successfully, continue in a new terminal (or quit wpa_supplicant with Template:Keypress and add the -B switch to the above command to run it in the background). WPA_Supplicant contains more information and troubleshooting.

Regardless of the method used, you can check if you have associated successfully:

# iw dev wlan0 link

Getting an IP address

Note: See Network Configuration#Configure the IP address for more examples. This part is identical.

Finally, provide an IP address to the network interface. Simple examples are:

# dhcpcd wlan0

for DHCP, or

# ip addr add dev wlan0
# ip route add default via

for static IP addressing.

Note: If you get a timeout error due to a waiting for carrier problem, then you might have to set the channel mode to auto for the specific device:
# iwconfig wlan0 channel auto

Before changing the channel to auto, make sure your wireless interface (in this case wlan0) is down. After it has successfully changed it, you can again bring the interface up and continue from there.

Custom startup scripts/services

Although the manual configuration method will help troubleshoot wireless problems, you will have to re-type every command each time you reboot. You can also quickly write a shell script to automate the whole process, which is still a quite convenient way of managing network connection while keeping full control over your configuration. You can find some examples in this section.

Manual wireless connection at boot using systemd and dhcpcd

This example uses systemd for start up, and dhcpcd and WPA supplicant for connecting.

Create a systemd unit, e.g /etc/systemd/system/network@.service:

Description=Network Connectivity (%i)

ExecStart=/usr/bin/ip link set dev %i up
ExecStart=/usr/bin/wpa_supplicant -B -i %i -c /etc/wpa_supplicant.conf
ExecStart=/usr/bin/dhcpcd %i


Enable the unit and start it, passing the name of the interface:

# systemctl enable network@wlp0s26f7u3.service
# systemctl start network@wlp0s26f7u3.service
Systemd with wpa_supplicant and static IP

Create configuration file for systemd unit:


Make sure that wpa_supplicant is installed and create /etc/wpa_supplicant.conf. See WPA supplicant for details.

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=network

Create a systemd unit file:

Description=Network Connectivity (%i)

ExecStart=/usr/bin/ip link set dev %i up
ExecStart=/usr/bin/wpa_supplicant -B -i %i -c /etc/wpa_supplicant.conf
ExecStart=/usr/bin/ip addr add ${address}/${netmask} broadcast ${broadcast} dev %i
ExecStart=/usr/bin/ip route add default via ${gateway}
ExecStop=/usr/bin/ip addr flush dev %i
ExecStop=/usr/bin/ip link set dev %i down


Enable the unit and start it, passing the name of the interface:

# systemctl enable network@wlp0s26f7u3.service
# systemctl start network@wlp0s26f7u3.service

Automatic setup

There are many solutions to choose from, but remember that all of them are mutually exclusive; you should not run two daemons simultaneously. The following table compares the different connection managers, additional notes are in subsections below.

Connection manager Network
(auto connect dropped
or changed location)
PPP support
(e.g. 3G modem)
Console tools
Connman Yes Yes Yes No connmanctl
Netctl Yes Yes Yes No netctl,wifi-menu
NetworkManager Yes Yes Yes Yes nmcli
Wicd Yes Yes No Yes wicd-curses


netctl is a replacement for netcfg designed to work with systemd. It uses a profile based setup and is capable of detection and connection to a wide range of network types. This is no harder than using graphical tools.

See: Netctl


Wicd is a network manager that can handle both wireless and wired connections. It is written in Python and Gtk with fewer dependencies than NetworkManager, making it an ideal solution for lightweight desktop users. Wicd is available in the official repositories.

See: Wicd

Note: wicd may cause excessive dropped connections with some drivers, while NetworkManager might work better.


NetworkManager is an advanced network management tool that is enabled by default in most popular GNU/Linux distributions. In addition to managing wired connections, NetworkManager provides worry-free wireless roaming with an easy-to-use GUI program for selecting your desired network.

If you do not use GNOME but use a window manager like Openbox or xmonad, do not forget to install polkit-gnome, gnome-keyring, libgnome-keyring, and pyxdg to manage WEP, WPA, and WPA2 connections.

See: NetworkManager

Note: GNOME's network-manager-applet also works under Xfce if you install xfce4-xfapplet-pluginAUR (available in the AUR) first. Additionally, there are applets available for KDE.

WiFi Radar

WiFi Radar is a Python/PyGTK2 utility for managing wireless profiles (and only wireless). It enables you to scan for available networks and create profiles for your preferred networks.

See: Wifi Radar


This section contains general troubleshooting tips, not strictly related to problems with drivers or firmware. For such topics, see next section.

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: Commands in following subsections need updating according to wireless_tools -> iw transition. (Discuss in Talk:Wireless network configuration#)

Power saving

See Power saving#Network interfaces.

Failed to get IP address

If getting an IP address repeatedly fails using the default dhcpcd client, try installing and using dhclient instead. Do not forget to select dhclient as the primary DHCP client in your connection manager!

If you can get an IP address for a wired interface and not for a wireless interface, try disabling the wireless card's power saving features:

# iwconfig wlan0 power off

Connection always times out

The driver may suffer from a lot of tx excessive retries and invalid misc errors for some unknown reason, resulting in a lot of packet loss and keep disconnecting, sometimes instantly. Following tips might be helpful.

Lowering the rate

Try setting lower rate, for example 5.5M:

# iwconfig wlan0 rate 5.5M auto

Fixed option should ensure that the driver does not change the rate on its own, thus making the connection a bit more stable:

# iwconfig wlan0 rate 5.5M fixed

Lowering the txpower

You can try lowering the transmit power as well. This may save power as well:

# iwconfig wlan0 txpower 5

Valid settings are from 0 to 20, auto and off.

Setting rts and fragmentation thresholds

Default iwconfig options have rts and fragmentation thresholds off. These options are particularly useful when there are many adjacent APs or in a noisy environment.

The minimum value for fragmentation value is 256 and maximum is 2346. In many windows drivers the maximum is the default value:

# iwconfig wlan0 frag 2346

For rts minimum is 0, maximum is 2347. Once again windows drivers often use maximum as the default:

# iwconfig wlan0 rts 2347

Random disconnections

Cause #1

If dmesg says wlan0: deauthenticating from MAC by local choice (reason=3) and you lose your Wi-Fi connection, it is likely that you have a bit too aggressive power-saving on your Wi-Fi card[2]. Try disabling the wireless card's power-saving features:

# iwconfig wlan0 power off

See Power saving for tips on how to make it permanent (just specify off instead of on).

If your card does not support iwconfig wlan0 power off, check the BIOS for power management options. Disabling PCI-Express power management in the BIOS of a Lenovo W520 resolved this issue.

Cause #2

If you are experiencing frequent disconnections and dmesg shows messages such as

ieee80211 phy0: wlan0: No probe response from AP xx:xx:xx:xx:xx:xx after 500ms, disconnecting

try changing the channel bandwidth to 20MHz through your router's settings page.

Troubleshooting drivers and firmware

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: This section may contain old information about modules that are now in kernel and work fine. (Discuss in Talk:Wireless network configuration#)

This section covers methods and procedures for installing kernel modules and firmware for specific chipsets, that differ from generic method.

See Kernel modules for general informations on operations with modules.



Unified driver for Ralink chipsets (it replaces rt2500, rt61, rt73, etc). This driver has been in the Linux kernel since 2.6.24, you only need to load the right module for the chip: rt2400pci, rt2500pci, rt2500usb, rt61pci or rt73usb which will autoload the respective rt2x00 modules too.

A list of devices supported by the modules is available at the project's homepage.

rt2860 and rt2870

From Linux kernel 3.0, the staging driver rt2860sta is replaced by the mainline driver rt2800pci, and rt2870sta is replaced by rt2800usb. As a result, the staging drivers are deleted. Source: Kernel commit. The rt2800 driver automatically works with devices using the rt2870 chipset.

It has a wide range of options that can be configured with iwpriv. These are documented in the source tarballs available from Ralink.


For devices which are using the rt3090 chipset it should be possible to use rt2860sta driver. The mainline driver rt2800pci is not working with this chipset very well (e.g. sometimes it's not possible to use higher rate than 2Mb/s).

The best way is to use the rt3090AUR driver from AUR. Compile the rt3090AUR driver from AUR, delete/move the /etc/Wireless/RT2860STA/RT2860STA.dat firmware file to allow installation of the compiled RT3090 package, blacklist the rt2860sta module and setup the rt3090sta module to load at boot.

Note: This driver also works for rt3062 chipsets.


The rt3290 chipset is recognised by the kernel rt2800pci module. However, some users experience problems and reverting to a patched Ralink driver seems to be beneficial in these cases.


New chipset as of 2012. It may require proprietary drivers from Ralink. Different manufacturers use it, see Belkin N750 example


New chipset as of 2012 with support for 5 Ghz bands. It may require proprietary drivers from Ralink and some effort to compile them. At the time of writing a how-to on compilation is available for a DLINK DWA-160 rev. B2 here.



The driver is now in the kernel, but many users have reported being unable to make a connection although scanning for networks does work.

The dkms-8192cuAUR package in the AUR may be a better choice for some users.


The driver is part of the current kernel package. The module initialization may fail at boot giving this error message:

rtl819xE:ERR in CPUcheck_firmware_ready()
rtl819xE:ERR in init_firmware() step 2
rtl819xE:ERR!!! _rtl8192_up(): initialization is failed!
r8169 0000:03:00.0: eth0: link down

A workaround is to simply unload the module:

# modprobe -r r8192e_pci

and reload the module (after a pause):

# modprobe r8192e_pci


The driver is part of the current kernel package. Firmware may need to be added manually if /usr/lib/firmware/RTL8192SU/rtl8192sfw.bin does not exist. (dmesg will report "rtl819xU:FirmwareRequest92S(): failed" if the firmware is missing)

To download and install firmware:

$ wget http://launchpadlibrarian.net/33927923/rtl8192se_linux_2.6.0010.1012.2009.tar.gz
# mkdir /lib/firmware/RTL8192SU
# tar -xzOf rtl8192se_linux_2.6.0010.1012.2009.tar.gz \
 rtl8192se_linux_2.6.0010.1012.2009/firmware/RTL8192SE/rtl8192sfw.bin > \
Note: An alternate version of the firmware may be found here, but this version may cause dropped connections.



There are three modules maintained by the MadWifi team:

  • ath_pci is the older driver.
  • ath5k will eventually phase out ath_pci. Currently a better choice for some chipsets, but not all chipsets are supported (see below)
  • ath9k is the new, official, superior driver for newer Atheros hardware (see below)

For old ath_pci driver, install package madwifiAUR and optionally madwifi-utils-svnAUR. Then:

# modprobe ath_pci

If using ath_pci, you may need to blacklist ath5k. See Kernel_modules#Blacklisting for instructions.

Some users may need to use the countrycode option when loading the MadWifi driver in order to use channels and transmit power settings that are legal in their country/region. In the Netherlands, for example, you would load the module like this:

# modprobe ath_pci countrycode=528

You can verify the settings with the iwlist command. See man iwlist and the CountryCode page on the MadWifi wiki. To have this setting automatically applied during boot, refer to Kernel_modules#Configuration, and note the following module option setting:

options ath_pci countrycode=528

See The MadWifi project's method of installing if you are having trouble after reading this article.


ath5k is the preferred driver for AR5xxx chipsets including those which are already working with madwifi-ng and for some chipsets older than AR5xxx.

If ath5k is conflicting with ath_pci on your system, blacklist (and unload using rmmod or reboot) the following drivers:


then modprobe ath5k manually or reboot. wlan0 (or wlanX) in sta mode should spawn and become ready to use.

If the device is unable to lease an IP after being loaded, try modprobe ath5k nohwcrypt=1. See below for details about the nohwcrypt option.


Note: Some laptop have problems with their wireless LED indicator flickering red and blue. To solve this problem, do:
echo none > "/sys/class/leds/ath5k-phy0::tx/trigger"
echo none > "/sys/class/leds/ath5k-phy0::rx/trigger"
For alternatives, look here.
Note: If you find web pages randomly loading very slow in Firefox/Opera/Chromium, or if the adapter has problems leasing an IP, try to switch from hardware to software encryption:
rmmod ath5k
modprobe ath5k nohwcrypt

And restart your connection. If it helps, make the change permanent by adding into /etc/modprobe.d/010-ath5k.conf:

options ath5k nohwcrypt
More about modprobe options: Modprobe#Options


ath9k is Atheros' officially supported driver for the newer 802.11n chipsets. All of the chips with 802.11n capabilities are supported, with a maximum throughput around 180 Mbps. To see a complete list of supported hardware, check this page.

Working modes: Station, AP and Adhoc.

ath9k has been part of the Linux kernel as of v2.6.27. (In the unlikely event that you have stability issues that trouble you, you could try using the compat-wireless package. An ath9k mailing list exists for support and development related discussions.)



ath9k_htc is Atheros' officially supported driver for 802.11n USB devices. Station and Ad-Hoc modes are supported. The driver is included in the kernel. For more information, see http://wireless.kernel.org/en/users/Drivers/ath9k_htc .


ipw2100 and ipw2200

These modules are fully supported in the kernel, but they require additional firmware. Depending on which of the chipsets you have, install either ipw2100-fw or ipw2200-fw. Then reload the appropriate module.

Tip: You may use the following module options:
  • use the rtap_iface=1 option to enable the radiotap interface
  • use the led=1 option to enable a front LED indicating when the wireless is connected or not

iwl3945, iwl4965 and iwl5000-series

Intel's open source Wi-Fi drivers for Linux (See iwlwifi) will work for both the 3945 and 4965 chipsets since kernel 2.6.24. And iwl5000-series chipsets (including 5100BG, 5100ABG, 5100AGN, 5300AGN and 5350AGN) have been supported since kernel 2.6.27, by the in-tree driver iwlagn.

Loading the Driver

udev should load the driver automatically, otherwise load iwl3945 or iwl4965 manually. See Kernel modules#Loading for details.

Disabling LED blink

The default settings on the module are to have the LED blink on activity. Some people find this extremely annoying. To have the LED on solid when Wi-Fi is active:

# echo 'w /sys/class/leds/phy0-led/trigger - - - - phy0radio' > /etc/tmpfiles.d/phy0-led.conf
# systemd-tmpfiles --create phy0-led.conf

To see all the possible trigger values for this LED:

# cat /sys/class/leds/phy0-led/trigger

Here is an example for the old way, if you do not have /sys/class/leds/phy0-led:

# echo "options iwlcore led_mode=1" >> /etc/modprobe.d/modprobe.conf
# rmmod iwlagn
# rmmod iwlcore
# modprobe iwlcore
# modprobe iwlagn

On Linux kernels and up, the iwlcore module was deprecated. Use options iwlagn led_mode=1 or options iwl_legacy led_mode=1 instead (find out what module is loaded with lsmod).

Note: iwl_legacy was renamed iwlegacy in Linux kernel 3.3.1. For this version, use options iwlegacy led_mode=1.
Other Notes
  • By default, iwl3945 is configured to only work with networks on channels 1-11. Higher frequency bands are not allowed in some parts of the world (e.g. the US). In the EU however, channels 12 and 13 are used quite commonly (and Japan allows for channel 14). To make iwl3945 scan for all channels, add options cfg80211 ieee80211_regdom=EU to /etc/modprobe.d/modprobe.conf. With iwlist frequency you can check which channels are allowed.
  • If you want to enable more channels on Intel Wifi 5100 (and quite possible other cards too), you can do that with the crda package. After installing the package, edit /etc/conf.d/wireless-regdom and uncomment the line where your country code is found. When executing iwlist wlan0 channel, you should now have access to more channels (depending on your location).


See Broadcom wireless.

Other drivers/devices

Tenda w322u

Treat this Tenda card as an rt2870sta device. See: rt2870


This should be a part of the kernel package and be installed already.

Note: Some Orinoco chipsets are Hermes I/II. You can use the AUR package wl_lkmAUR to replace the orinoco driver and gain WPA support. See this post for more information.

To use the driver, blacklist orinoco_cs, and then add wlags49_h1_cs.


Download the firmware driver for your appropriate card from this site. Rename the firmware file to isl3890. If non-existent, create the directory /usr/lib/firmware and move the file isl3890 inside it. This should do the trick. [3]

If that did not work, try this:

  • Reload the prism module (modprobe p54usb or modprobe p54pci, depending on your hardware)

Alternatively, remove your Wi-Fi card and then reconnect it.

  • Use the dmesg command, and look at the end of the output it prints out.

Look for a section similar to this:

firmware: requesting isl3887usb_bare
p54: LM86 firmware
p54: FW rev - Softmac protocol 3.0

and try renaming the firmware file to the name corresponding to the part bolded here.

If you get the message

SIOCSIFFLAGS: Operation not permitted

when performing ip link set wlan0 up OR

prism54: Your card/socket may be faulty, or IRQ line too busy :(

appears in dmesg's output this may be because you have both the deprecated kernel module prism54 and one of the newer kernel modules (p54pci or p54usb) loaded at the same time and they are fighting over ownership of the IRQ. Use the command lsmod | grep prism54 to see if the deprecated module is being loaded. If so, you need to stop prism54 from loading by blacklisting it (there are several ways to do this which are described elsewhere). Once blacklisted, you may find you have to rename the firmware as prism54 and p54pci/p54usb look for different firmware filenames (i.e. recheck the dmesg output after performing ip link set eth0 up).


Packages: tiacx tiacx-firmware

The driver should tell you which firmware it needs; check /var/log/messages.log or use the dmesg command.

Link the appropriate firmware to /usr/lib/firmware:

ln -s /usr/share/tiacx/acx111_2.3.1.31/tiacx111c16 /usr/lib/firmware

For another way to determine which firmware revision number to use, see the "Which firmware" section of the acx100.sourceforge wiki. For ACX100, you can follow the links provided there to a table of card model numbers vs. "firmware files known to work"; you can figure out the rev. number you need, by looking at the suffix there. For example, a dlink_dwl650+ uses "1.9.8.b", in which case you would do this:

ln -s /usr/share/tiacx/acx100_1.9.8.b/* /usr/lib/firmware

If you find that the driver is spamming your kernel log, for example because you are running Kismet with channel-hopping, you could put this in /etc/modprobe.d/modprobe.conf:

options acx debug=0
Note: The open-source acx driver does not support WPA/RSN encryption. Ndiswrapper will have to be used with the Windows driver to enable the enhanced encryption. See ndiswrapper, this page, for more details.


zd1211rw is a driver for the ZyDAS ZD1211 802.11b/g USB WLAN chipset, and it is included in recent versions of the Linux kernel. See [4] for a list of supported devices. You only need to install the firmware for the device, provided by the zd1211-firmware package.


carl9170 is the 802.11n USB driver with GPLv2 firmware for Atheros USB AR9170 devices. It supports these devices. The firmware is not yet part of the linux-firmware package; it is available in the AUR (carl9170-fwAUR). The driver is a part of the Linux kernel v2.6.37 and higher.

In order to use this driver, the following older driver modules must be blacklisted:

  • arusb_lnx
  • ar9170usb


Host AP is the Linux driver for Prism2/2.5/3 like WCP11. hostap_cs should be a part of the linux package and should be installed already.

orinico_cs can cause problems, so it must be blacklisted. After blacklisting, the driver should work.

See official site for more information.


Ndiswrapper is a wrapper script that allows you to use some Windows drivers in Linux. See the compatibility list here. You will need the .inf and .sys files from your Windows driver. Be sure to use drivers appropriate to your architecture (x86 vs. x86_64).

Tip: If you need to extract these files from an *.exe file, you can use cabextract.

Follow these steps to configure ndiswrapper.

1. Install the driver to /etc/ndiswrapper/*

ndiswrapper -i filename.inf

2. List all installed drivers for ndiswrapper

ndiswrapper -l

3. Write configuration file in /etc/modprobe.d/ndiswrapper.conf

ndiswrapper -m
depmod -a

Now the ndiswrapper install is almost finished; follow the instructions on Kernel modules#Loading to automatically load the module at boot.

The important part is making sure that ndiswrapper exists on this line, so just add it alongside the other modules. It would be best to test that ndiswrapper will load now, so:

modprobe ndiswrapper

and wlan0 should now exist. Check this page if you are having problems: Ndiswrapper installation wiki.


Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: compat-drivers-patchedAUR has reached end-of-life, backports-patchedAUR should be used instead (Discuss in Talk:Wireless network configuration#)

Patched compat wireless drivers correct the "fixed-channel -1" issue, whilst providing better injection. Please install the compat-drivers-patchedAUR package from the AUR.

compat-drivers-patchedAUR does not conflict with any other package and the modules built reside in /usr/lib/modules/your_kernel_version/updates.

These patched drivers come from the Linux Wireless project and support many of the above mentioned chips such as:

ath5k ath9k_htc carl9170 b43 zd1211rw rt2x00 wl1251 wl12xx ath6kl brcm80211

Supported groups:

atheros ath iwlagn rtl818x rtlwifi wl12xx atlxx bt

It is also possible to build a specific module/driver or a group of drivers by editing the PKGBUILD, particularly uncommenting the line #46. Here is an example of building the atheros group:

scripts/driver-select atheros

Please read the package's PKGBUILD for any other possible modifications prior to compilation and installation.

See also