[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: is there program that decipher wireless password

Some more help:
Installing Drivers

As of now, Aireplay-ng only supports injection on Prism2, PrismGT, Atheros, 
Broadcom (with the b43 driver), Intel IWL, RTL8180, RTL8187, Ralink, ACX1xx 
and Zydas. Injection on Hermes, Aironet and Marvell is not supported because 
of firmware and/or driver limitations.

There are two families of drivers - ieee80211 and mac80211. Basically, 
mac80211 has largely replaced ieee80211. See this write-up for more detail. 
Where the mac80211 version of the driver is stable and supports injection, 
that should be your first choice. Keeping in mind that mac80211 is only well 
supported starting in about 2.6.25 and up kernels. However, in some cases, 
only legacy ieee80211 drivers exist for injection.

Nearly all non-mac80211 drivers that can support injection need to be patched 
to support injection in Monitor mode. On the other hand, the mac80211 versions 
of the drivers generally only need the mac80211 core itself patched to support 
the fragmentation attack. Other attacks using mac80211 drivers typically work 
without patching.

Remember you cannot use both ieee80211 and mac80211 versions of the same 
driver at the same time. You must decide to use one or the other, not both. If 
you try loading both, one will fail. So you must consciously decide which one 
you wish to use and blacklist the other one if you have both on your system.

You will need the following to compile drivers:

      Linux kernel headers that match your current running kernel. On 
openSUSE, the kernel sources also must be installed. Depending on the driver 
and distribution, you must install the full kernel sources as well.
      The same gcc version that was used to compile your kernel. At least make 
sure that the first two version numbers or the compiler are the same (e.g. 
it's OK to use gcc 3.4.6 to compile the driver if the kernel was compiled by 
gcc 3.4.2). Ignoring this rule will cause Invalid module format errors during 
module load. That can be checked via /proc/version.
      Always use the latest patches that you can find here

Note: if you're using drivers provided by your distribution, they are NOT 
General information about patching drivers plus troubleshooting tips can be 
found in the How To Patch Drivers Tutorial.

The following are detailed instructions for installing/patching the ieee80211 
versions of the drivers:

      HostAP (prism2)
      wlan-ng (prism2)

For fragmentation support, all mac80211 drivers require the mac80211 core to 
be patched:

      mac80211 core patching instructions

The mac80211 link above also contains information regarding which mac80211 
drivers work with the aircrack-ng suite.

In addition, the following mac80211 drivers require extra patches to enable or 
improve monitoring or injection support (purpose of the patch is in 

      iwlagn (allow injection in 2.6.25/.26, formerly called iwl4965)
      rtl8187 (improve injection speed)
      zd1211rw-mac80211 (fully disable packet filtering in monitor mode)

Note: For other drivers, simply follow the standard installing procedure for 
your distribution.
Compat-Wireless Alternative Approach

As mentioned previously, the mac80211 drivers quite often support injection 
out of the box in recent kernels. The mac80211 drivers are improving very 
rapidly. Sometimes you want to try the latest mac80211 driver without 
recompiling your entire kernel. This is where Compat-Wireless comes in. You 
can now download a package which lets you compile and install the latest 
advances on the Linux wireless subsystem and get some of the latest drivers 
without having to recompile your entire kernel. This package adds mac80211, 
mac80211 drivers, and any new FullMAC driver which has had fairly recent 

For full details see the Aircrack-ng Compat-Wireless documentation.

Windows is NOT supported.

This troubleshooting information applies to linux only. The individual driver 
pages may have additional troubleshooting information specific to that driver. 
This troubleshooting information provides general information which applies to 
all drivers.

You will need to do a bit of homework first prior to following the 
troubleshooting tips below. Be sure you know the chipset in your wireless 
device. Follow this tutorial Tutorial: Is My Wireless Card Compatible? to 
determine the chipset if you don't already know it. Based on the chipset, 
determine the proper driver and in turn the kernel modules for it. To do this, 
you may have to search the internet, the forum and the distribution support.
Hardware Verification

The first critical step is to ensure that your wireless device is recognized 
by your system. There are a variety of methods to verify that your system did 
this successfully. Here are some methods:

      The “dmesg” command can quite often contain detailed messages indicating 
that the wireless devices was properly detected.
      If the card is an ISA card, you are usually out of luck.
      If the card is a PCI card (miniPCI/miniPCI Express/PCI Express), you 
need to use the command “lspci” to display the card identification strings.
      If the hardware is a USB dongle, you need to use the command “lsusb” to 
display the dongle identification strings. In some case, “lsusb” doesn't work 
(for example if usbfs is not mounted), and you can get the identification 
strings from the kernel log using “dmesg” (or in /var/log/messages).
      If the card is a Cardbus card (32 bits PCMCIA), and if you are using 
kernel 2.6.X or kernel 2.4.X with the kernel PCMCIA subsystem, you need to use 
the command “lspci” to display the card identification strings. If the card is 
a Cardbus card (32 bits PCMCIA), and if you are using an older kernel with the 
standalone PCMCIA subsystem, you need to use the command “cardctl ident” 
display the card identification strings. Try both and see what comes out.
      If the card is a true PCMCIA card (16 bits), and if you are using kernel 
2.6.14 or later, you need to use the command “pccardctl ident” to display the 
card identification strings. If the card is a true PCMCIA card (16 bits), and 
if you are using an older kernel, you need to use the command “cardctl ident” 
display the card identification strings. Note that cardmgr will also write 
some identification strings in the message logs (/var/log/daemon.log) that may 
be different from the real card identification strings. Usually 16bit PCMCIA 
cards can be easily identified by the sticker on the bottom of the card with 
tick boxes or information indicating its a 5V card.

Needless to say, if your wireless device is not detected by your system, you 
will have to investigate and correct the problem.

Start by running “modprobe <kernel module name>”.
View iwconfig output

Run the “iwconfig” command and look for wireless devices. Based on the driver, 
look for an appropriately named interface such as ath0, rausb0, etc. The 
presence indicates that at least the driver is loaded. The absence likely 
means it did not. This at least gives you a starting point on the problem 

A common problem is that your system has both ieee80211 and mac80211 versions 
of the drivers. Having wmaster0 typically indicates you are using the new 
mac80211 drivers. Having wifi0 or eth0 typically means you are using the older 
(legacy) ieee80211 drivers. Having both wmaster0 and wifi0/eth0 (as well as 
weird interface names like wlan0_rename) might indicate a udev problem. Based 
on what which ones you really want, you may have to blacklist or move one or 
more drivers.
View dmesg output

Run the “dmesg” command and look for errors relating to your wireless device. 
At a minimum there should be some messages relating to your device loading and 
the module initializing it. If there are no messages or errors, you will have 
to investigate and correct the problem.

See the next entry of a problem commonly seen: “unknown symbol”.
"unknown symbol" error

When loading the driver kernel module you get a “unknown symbol” error message 
for one more field names. Sometimes you will see this in the dmesg output as 
well. This is caused by module you are loading not being matching the kernel 
version you are running.

First, determine which kernel you are running with “uname -r”. Then use your 
package manager to determine if you have kernels, kernel headers or kernel 
development packages that are older.

If you use the RPM package manager then “rpm -qa | grep kernel”. So if you get 
something like:


In the example above, there are kernel headers and a kernel development 
package that match the kernel we are running. If you are missing them, the use 
yum or equivalent on your distribution to install them such as:

 yum -y install kernel-headers
 yum -y install kernel-devel

Lets assume that “uname -r” returned “” then all the ones are old and need to be removed. So you remove all the old 

 rpm -e
 rpm -e kernel-
 rpm -e kernel-devel-

Also change to ”/lib/modules” and do a directory listing and remove any 
directory referring to old kernel versions.

Once you are finished, you can do ”“rpm -qa | grep kernel” and confirm 
everything looks good. At this point, recompile your wireless drivers and 
reboot the system.
View lsmod output

Run the “lsmod” command can be used to see the loaded modules. Confirm that 
the kernel module for your wireless device is actually loaded. If it is not 
loaded, you will have to investigate and correct the problem.

Sometimes other modules conflict with the one you are trying to run. See 
blacklisting below. Additionally, conflicting modules can be moved out of the 
module tree. If you do this, run “depmod -ae” afterwards.
View modinfo output

Run “modinfo <kernel module name>”. This will confirm the module is actually 
in the modules tree. As well, confirm it is the correct version. Do a “ls -l 
<file location per modinfo>” and confirm the date matches when you compiled 
it. It is not uncommon that you are not running the correct module version.

A common problem on newer kernels is that the new mac80211 version of the 
driver gets loaded instead of the older legacy driver, or vice versa. If that 
is the case, then you need to blacklist the wrong modules by editing 
/etc/modprobe.d/blacklist. First, determine the broken module names and add 
them to the blacklist file as “blacklist <module name>”.

Specifically for madwifi-ng, do a locate or find for ath5k.ko. If ath5k.ko 
exists then add “blacklist ath5k” to /etc/modprobe.d/blacklist and reboot. 
Same for the other way around: if you want to load ath5k, but madwifi-ng gets 
loaded instead, add “blacklist ath_pci” to /etc/modprobe.d/blacklist.
Reload Driver

Although it is not very “scientific”, sometimes simply unloading then 
reloading the driver will get it working. This is done with the rmmod and 
modprobe (or simply modprobe -r and then modprobe) commands.

For b43 and b43legacy, it might also be necessary to reload the underlying SSB 
module. Similarly, rt2x00 and p54 might need reloading of the common modules 
(p54common, rt2x00lib, rt2x00usb, rt2x00pci). Sometimes (especially with 
mac80211 drivers), reloading the stack (for example, modules “cfg80211” and 
“mac80211”) might do the trick. Also another trick is to do modprobe –show-
depends <driver>.

For USB devices, the trick to reloading the driver is to make sure all of its 
related interfaces are down (usually wlan0, mon0, etc if you only have one USB 
device). Then you modprobe -r via the driver it is using and reload those 
drivers again via modprobe.

For PCMCIA devices, it is recommended that you have pcmcia-cs package 
installed as it has a handy utility known as pccardctl. To eject the device 
virtually, make sure that the interfaces are down following similar guide to 
USB devices. Once they are down, use pccardctl eject to virtually eject the 
card/s. Remove all the modules related to the card (hint: if you weren't 
familiar with the drivers that were used, before you eject the card/s make 
sure that you do lspci -k as this will list all the devices connected via PCI 
bus and their related drivers). Once you have removed it, do pccardctl insert 
and the driver should be loaded automatically. If not load them manually via 

For PCI devices, there is no real shortcut as the device will remain 
permanently used by the driver. You will need to reboot for the new driver to 
take effect.
mac80211 versus ieee80211 stacks

There is a new wireless stack starting in the mainline kernel since 2.6.22 
called mac80211. As newer versions of the kernel get released more and more 
wireless devices are being supported by it. It has the huge advantage of being 
included in the kernel itself. The mac80211 stack has features such as 
software MAC (media access controller), hostapd, WEP, WPA, WME, a “link-layer 
bridging module,” and a QoS (quality of service) implementation. Of specific 
interest to aircrack-ng is native monitor mode and injection support.

The legacy drivers use the ieee80211 or net80211 stacks. And quite often there 
is one stack per wireless device. Depending on the driver, it does not provide 
native monitor mode or injection support.

So with this as background, here is troubleshooting information for problems 
that arise when both stacks are installed on a system. There are four classes 
of problems:

      The mac80211 driver for your wireless device is not stable or the 
monitor mode / injection functionality is not working well.
      You are using a mac80211 driver, but your aircrack-ng version is too old 
to support Radiotap.
      You are using the legacy driver for your device and want to switch to 
the mac80211 driver.
      The old and new modules conflict.

You can tell if you are running the new mac80211 stack based on the kernel 
version or you likely get an error message similar to:

 airmon-ng start wlan0

 Interface       Chipset         Driver
 wlan0                   iwl4965 - [phy0]/usr/sbin/airmon-ng: line 338: 
/sys/class/ieee80211/phy0/add_iface: Permission denied
                                 mon0: unknown interface: No matching device 
                                 (monitor mode enabled on mon0)

or in aircrack-ng v1.0-rc1 and newer:

 airmon-ng start wlan0

 Interface       Chipset         Driver
 wlan0                   iwl4965 - [phy0]
 ERROR: Neither the sysfs interface links nor the iw command is available.
 Please download and install iw from http://dl.aircrack-ng.org/iw.tar.bz2

Notice the reference to “phy0” and “mon0”. Read the page mac80211 for a fix 
for this error. if the error doesn't show up, then the correct output of 
airmon-ng is like this:

 airmon-ng start wlan0

 Interface       Chipset         Driver
 wlan0                   iwl4965 - [phy0]
                                 (monitor mode enabled on mon0)

Another indicator of the mac80211 driver being loaded is if the output from 
iwconfig includes:

 wmaster0  no wireless extensions. 

Notice the reference to “wmaster0”.

Perhaps the most consistent way of determining the stack type of your drivers 
is running the command “lsmod | grep mac80211.” If the output includes a line 
like this:

 mac80211              229108  4 rt2x00usb,b43,rt2x00lib,zd1211rw

then the modules at the end of the line are mac80211 drivers.

If the new mac80211 driver is not working to your satisfaction then you will 
have to blacklist it and then use the ieee80211 legacy version. The wiki 
driver section on this page has links to the various drivers.

It is also possible that the new driver is not working because your version of 
aircrack-ng is too old. Updating to at least 1.0-rc1 often fixes such 

If you are using a legacy driver, and want to switch to the mac80211 driver, 
then you need to blacklist the old driver, and enable the new one. If the 
names of the old and new in-kernel drivers match (for example, with zd1211rw, 
which is softmac in 2.6.24 and before, but mac80211 in 2.6.25), then you need 
to upgrade your wireless subsystem (either by updating the kernel or using 

If you have conflicts due to running both drivers, then decide which one you 
want and blacklist the other one.
dmesg error "failed with error -71" for USB device

When using an USB device and you get a message similar to this from dmesg:

 rt73: Firmware loading error
 rt73: Failed to load Firmware.
 rt73: probe of 1-7:1.0 failed with error -71

Note: Although the example shows RT73, this applies to any USB driver.

Here are a few things to check:

      Ensure you have the firmware installed on your system and in the correct 
location. usually its in /lib/firmware or /lib/firmware-`uname-r`.
      You can try downloading a fresh copy of the driver and installing it 
      Try connecting your USB device directly to your computer without a 
cable. Cables can be defective and/or too long. If they are too long then the 
signal may degrade or there is insufficient power.
      If you have multiple USB devices connected to your computer then remove 
them all except the wireless device and retry.


Laptop Specific

Some laptops have a bios setting and/or a physical switch to enable/disable 
internal wireless cards. Make sure that these are are all “turned on” so that 
your wireless card is operational.
Laptop Specific

me laptops have a bios setting and/or a physical switch to enable/disable 
internal wireless cards. Make sure that these are are all “turned on” so that 
your wireless card is operational. 

Reply to: