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.

Note:

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. Make sure to blacklist the unwanted module.

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 that your wireless chipset requires a firmware to function.

The need for network profiles, if the computer will frequently change networks (such as a laptop).

Tip:

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:

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.

Note:

Examples in this section assume that your wireless device is wlan0 and that you are connecting to your_essid wifi access point. 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 dev wlan0 set type ibss

iwconfig wlan0 mode ad-hoc

Setting the operation mode to ad-hoc.

iw dev wlan0 connect your_essid

iwconfig wlan0 essid your_essid

Connecting to open network.

iw dev wlan0 connect your_essid 2432

iwconfig wlan0 essid your_essid freq 2432M

Connecting to open network specifying channel.

iw dev 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 dev 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.

Interface activation

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. See #Rfkill caveat for details.

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:

SSID: the name of the network.

Signal: is reported in a wireless power ratio in dbm (e.g. from -100 to 0). The closer the negative value gets to zero, the better the signal. Observing the reported power on a good quality link and a bad one should give an idea about the individual range.

Security: it is not reported directly, check the line starting with capability. If there is Privacy, for example capability: ESS Privacy ShortSlotTime (0x0411), then the network is protected somehow.

If you see an RSN information block, then the network is protected by Robust Security Network protocol, also known as WPA2.

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.

If you do not see neither RSN nor WPA blocks but there is Privacy, then WEP is used.

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 ibss:

# iw dev 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).

Association

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 dev wlan0 connect your_essid

WEP

using a hexadecimal or ASCII key (the format is distinguished automatically, because a WEP key has a fixed length):

# iw dev 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, four are possible):

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 Ctrl+c 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:

Tip: dhcpcd contains a hook (enabled by default) to automatically launch WPA supplicant on wireless interfaces. It is started only if a configuration file at /etc/wpa_supplicant.conf exists and no wpa_supplicant process is listening on that interface. In most cases, you do not need to create any custom service, just enable dhcpcd@interface.

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.

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.

Netctl

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.

Wicd

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.

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

NetworkManager

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.

Rfkill caveat

Many laptops have a hardware button (or switch) to turn off wireless card, however, the card can also be blocked by kernel. This can be handled by rfkill. Use rfkill to show the current status:

# rfkill list

0: phy0: Wireless LAN
Soft blocked: yes
Hard blocked: yes

If the card is hard-blocked, use the hardware button (switch) to unblock it. If the card is not hard-blocked but soft-blocked, use the following command:

# rfkill unblock wifi

Note: It is possible that the card will go from hard-blocked and soft-unblocked state into hard-unblocked and soft-blocked state by pressing the hardware button (i.e. the soft-blocked bit is just switched no matter what). This can be adjusted by tuning some options of the rfkillkernel module.

Observing Logs

A good first measure to troubleshoot is to analyze the system's logfiles first. In order not to manually parse through them all, it can help to open a second terminal/console window and watch the kernels messages with

$ dmesg -w

while performing the action, e.g. the wireless association attempt.

When using a tool for network management, the same can be done for systemd with

# journalctl -f

The individual tools used in this article further provide options for more detailed debugging output, which can be used in a second step of the analysis, if required.

Power saving

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

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 is down. After it has successfully changed it, you can bring the interface up again and continue from there.

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

Troubleshooting drivers and firmware

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.

Ralink

rt2x00

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.

Additional notes

Since kernel 3.0, rt2x00 includes also these drivers: rt2800pci, rt2800usb.

Since kernel 3.0, the staging drivers rt2860sta and rt2870sta are replaced by the mainline drivers rt2800pci and rt2800usb[3].

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

rt3090

For devices which are using the rt3090 chipset it should be possible to use rt2800pci driver, however, 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. Make sure to blacklist the rt2800pci module and setup the rt3090sta module to load at boot.

Note: This driver also works with rt3062 chipsets.

rt3290

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.

rt3573

rt5572

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.

Realtek

rtl8192cu

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.

rtl8192e

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

rtl8188eu

Some dongles, like the TP-Link TL-WN725N v2 (not sure, but it seems that uses the rtl8179 chipset), use chipsets compatible with this driver. In order to use it you have to install the dkms-8188euAUR package in the AUR.

Atheros

The MadWifi team currently maintains three different drivers for devices with Atheros chipset:

madwifi is an old, obsolete driver. Not present in Arch kernel since 2.6.39.1[4].

ath5k is newer driver, which replaces the madwifi driver. Currently a better choice for some chipsets, but not all chipsets are supported (see below)

ath9k is the newest of these three drivers, it is intended for newer Atheros chipsets. All of the chips with 802.11n capabilities are supported.

ath5k

If you find web pages randomly loading very slow, or if the device is unable to lease an IP address, try to switch from hardware to software encryption by loading the ath5k module with nohwcrypt=1 option. See Kernel Modules#Options for details.

Some laptops may have problems with their wireless LED indicator flickering red and blue. To solve this problem, do:

ath9k

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.

Asus

With some Asus laptops (tested with Asus U32U series) it could help to add options asus_nb_wmi wapf=1 to /etc/modprobe.d/asus_nb_wmi.conf to fix rfkill related issues.

Intel

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.

If you have problems connecting to networks in general or your link quality is very poor, try to disable 11n and enable software encryption:

/etc/modprobe.d/iwlwifi.conf

options iwlwifi 11n_disable=1
options iwlwifi swcrypto=1

Disabling LED blink

Note: This works with the iwlegacy and iwlwifi drivers.

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, you can use the systemd-tmpfiles:

/etc/tmpfiles.d/phy0-led.conf

w /sys/class/leds/phy0-led/trigger - - - - phy0radio

Run systemd-tmpfiles --create phy0-led.conf for the change to take effect, or reboot.

To see all the possible trigger values for this LED:

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

Tip: If you do not have /sys/class/leds/phy0-led, you may try to use the led_mode="1"module option. It should be valid for both iwlwifi and iwlegacy drivers.

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).

ACX100/111

zd1211rw

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 [5] for a list of supported devices. You only need to install the firmware for the device, provided by the zd1211-firmware package.

hostap_cs

Host AP is a Linux driver for wireless LAN cards based on Intersil's Prism2/2.5/3 chipset. The driver is included in Linux kernel.

Note: Make sure to blacklist the orinico_cs driver, it may cause problems.

ndiswrapper

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: