Before wpa_supplicant can do its work, the network interface must be available and the driver for the device must be loaded. wpa_supplicant allows one to specify driver with "-D" flag. I have tried this on few systems, but wpa_supplicant never seems to accept the driver I have specified. For example:

T42 ~ # lspci -v -s 02:02.0
02:02.0 Network controller: Intel Corporation PRO/Wireless 2915ABG [Calexico2] Network Connection (rev 05)
    Subsystem: Intel Corporation Device 1011
    Flags: bus master, medium devsel, latency 64, IRQ 11
    Memory at c0214000 (32-bit, non-prefetchable) [size=4K]
    Capabilities: [dc] Power Management version 2
    Kernel driver in use: ipw2200
    Kernel modules: ipw2200
T42 ~ # wpa_supplicant -D ipw2200 -i eth1 -c /root/wpafile 
Unsupported driver 'ipw2200'.
T42 ~ # 

However, if I start wpa_supplicant without specifying the driver like wpa_supplicant -i eth1 -c /root/wpafile, then it works flawlessly. Why is this so? In addition, in which case it's needed to specify driver for wpa_supplicant?

  • 1
    List of available drivers includes (see manual): HostAP, Prism54, Madwifi, NDISWrapper, AMTEL, IPW (both 2100 and 2200 drivers), WEXT (Generic Linux wireless extensions), Wired ethernet. Of those most interesting are WEXT (which is in use for 70% Wifi devices), NDISWrapper if you're using Windows drivers, wrapped by Linux compatibility layer and Madwifi, if you're using aircrack. Though, I don't understand from the architectural point of view, what level those drivers represent. Oct 27, 2013 at 23:42

1 Answer 1


You are confusing kernel drivers and user-space drivers. In your case, you may certainly use WEXT, but also nl80211 (I think).

WEXT (or WE= Wireless Extensions) are the modification introduced to the Linux kernel in 1997 by Jean Tourrhiles. According to this Web page written by Tourrhiles himself,

The Wireless Extension (WE) is a generic API allowing a driver to expose to the user space, configuration and statistics specific to common Wireless LANs. The beauty of it is that a single set of tool can support all the variations of Wireless LANs, regardless of their type (as long as the driver support Wireless Extension). Another advantage is these parameters may be changed on the fly without restarting the driver (or Linux).

In other words, WEXT sits on top of your driver, and allows wpa_supplicant to interact with it. Notice that wpa_supplicant and the driver belong to different kernel realms, (the first to user-space, the second to kernel-space), thus an API capable of acting as a go-between is required. This is the role played by the so-called drivers mentioned by Bob.

However, this Linux-Wireless Web page states explicitly that

Is WE being further developed ?

No it is not. Only bug fixes are being accepted for WE.


What is Wireless-Extensions' replacement?

New development should be focused on cfg80211 and nl80211.

In fact, if a query my wpa_supplicant drectly (i.e., not the man page, but the command

 wpa_supplicant -h

I get (in part) this reply:

  wext = Linux wireless extensions (generic)
  nl80211 = Linux nl80211/cfg80211
  wired = Wired Ethernet driver
  none = no driver (RADIUS server/WPS ER)

In other words, faithful to Linux Wireless's words, support to all other drivers except Wext and nl80211 has been dropped, and the support to Wext has been maintained because ...

Do we still use WE ?

Yes cfg80211 and nl80211 are still being worked on so WEs are still being used. All mac80211 drivers support WEs as mac80211 uses it. The idea is to slowly start moving things onto cfg80211 and nl80211 which are not there yet and add any new features to them as well.

This applies to Linux Kernel 3.11.1-031101-generic.

Those of you who have used hostapd are, in a way, already informed of all this, because the standard driver for hostapd is exactly nl80211.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .