Run 'aircrack-ng | head'. Version information is in the first line of text (second if the empty line is taken into account).

Which card to purchase is a hard question to answer. Each person's criteria is somewhat different, such as one may require 802.11ax capability, or may require it to work via virtualization. However, having said that, then the following cards are considered the best in class:

• Alfa AWUS036AXML (a/b/g/n/ac/ax, WiFi 6E) is the best performing card, with a stable driver
• Alfa AWUS036AXM (a/b/g/n/ac/ax, WiFi 6E) has been reported as a bit less sensitive than the AWUS036AXML

Runner ups:

• Alfa AWUS036ACH (a/b/g/n/ac) is the best performing card, but the driver can be unstable enough to crash your kernel
• Alfa AWUS036ACM (a/b/g/n/ac) is the highest performing of the STABLE devices, but it requires kernel 4.19.5 or higher, and the driver doesn't work on the Raspberry Pi 3 yet; it works on the Raspberry Pi 4.

Older adapters:

• Alfa AWUS036H [b/g USB]
• Ubiquiti SRC [a/b/g Cardbus]
• Ubiquiti SRX [a/b/g ExpressCard]
• Airpcap series [USB]
• TP-Link TL-WN722N v1 [b/g/n USB] - Beware, if version is not specified by vendor, it is NOT v1
• Alfa AWUS036NHA [b/g/n USB]
• Alfa AWUS051NH v2 [a/b/g/n USB]
• MiniPCIe: anything that uses ath9k, especially AR92xx and AR93xx (ability to do spectral scan)

Also read this first before purchasing. There are many available on the market for fairly low prices. You are simply trading off distance, sensitivity and performance for cost.

If you want to know if your existing card is compatible then use this page: Tutorial: Is My Wireless Card Compatible?

The Tutorials page has many tutorials specific to the aircrack-ng suite. If your question is not answered on this FAQ page, be sure to check out these other resources:

• The Forum
• User Documentation by platform (Linux, Windows)

The links page also generic wireless information and tutorials.

The following 2 devices have been tested and work fine:

• BU-353
• NL-402U USB
• VK-192 devices
• Stratux GPYes 2.0

However, anything that is compatible with GPSd will work.

After you enter “make install” then try to use any of the aircrack-ng suite commands, you get the error message “command not found” or similar. See the tip with the same message in troubleshooting tips.

The basic idea is to capture as much encrypted traffic as possible using airodump-ng. Each WEP data packet has an associated 3-byte Initialization Vector (IV): after a sufficient number of data packets have been collected, run aircrack-ng on the resulting capture file. aircrack-ng will then perform a set of statistical attacks developed by a talented hacker named KoreK.

Since that time, the PTW approach (Pychkine, Tews, Weinmann) has been developed. The main advantage of the PTW approach is that very few data packets are required to crack the WEP key.

WEP cracking is not an exact science. The number of required IVs depends on the WEP key length, and it also depends on your luck. Usually, 40-bit WEP (64 bit key) can be cracked with 300,000 IVs, and 104-bit WEP (128 bit key) can be cracked with 1,500,000 IVs; if you're out of luck you may need two million IVs, or more.

There is no way to know the WEP key length: this information is kept hidden and never announced, either in management or data packets; as a consequence, airodump-ng can not report the WEP key length. Thus, it is recommended to run aircrack-ng twice: when you have 250,000 IVs, start aircrack-ng with “-n 64” to crack 40-bit WEP. Then if the key is not found, restart aircrack-ng (without the -n option) to crack 104-bit WEP.

The figures above are based on using the Korek method. With the introduction of the PTW technique in aircrack-ng 0.9 and above, the number of data packets required to crack WEP is dramatically lowered. Using this technique, 40-bit WEP (64 bit key) can be cracked with as few as 20,000 data packets and 104-bit WEP (128 bit key) with 40,000 data packets. PTW is limited to 40 and 104 bit keys lengths. Keep in mind that it can take 100K packets or more even using the PTW method. Additionally, PTW only works properly with selected packet types. Aircrack-ng defaults to the PTW method and you must manually specify the Korek method in order to use it.

You can't know what's the key length, there's no information at all in wireless packets, that's why you have to try different lengths. Most of the time, it's a 128 bit key.

Just because you seem to have successfully connected to the access point doesn't mean your WEP key is correct! To check your WEP key, the best way is to decrypt a capture file with the airdecap-ng program.

You must sniff until a handshake takes place between a wireless client and the access point. To force the client to reauthenticate, you can start a deauth attack with aireplay-ng. Also, a good dictionary is required.

FYI, it's not possible to pre-compute large tables of Pairwise Master Keys like rainbowcrack does, since the passphrase is salted with the ESSID.

The easiest way is do an Internet search for word lists and dictionaries. Also check out web sites for password cracking tools. Many times they have references to word lists. A few sources follow. Please add comments or additions to this thread: https://forum.aircrack-ng.org/index.php?topic=1373.0.

Remember that valid passwords are 8 to 63 characters in length. The Aircrack-ng Other Tips page has a script to eliminate passwords which are invalid in terms of length.

• OpenWall:
  • ftp://ftp.openwall.com/pub/wordlists/
  • https://www.openwall.com/mirrors/
• GitHub
  • https://github.com/danielmiessler/SecLists/tree/master/Passwords
  • https://github.com/berzerk0/Probable-Wordlists
  • https://github.com/search?q=wordlist
• ftp://ftp.cerias.purdue.edu/pub/dict/
• https://www.outpost9.com/files/WordLists.html
• http://www.vulnerabilityassessment.co.uk/passwords.htm
• https://packetstormsecurity.com/Crackers/wordlists/
• http://ai1.ai.uga.edu/ftplib/natural-language/moby/
• http://wordlist.aspell.net/

You have to use WZcook

It's extremely unlikely that WPA will be cracked just like WEP was.

The major problem with WEP is that the shared key is appended to the IV; the result is directly used to feed RC4. This overly simple construction is prone to a statistical attack, since the first ciphertext bytes are strongly correlated with the shared key (see Andrew Roos' paper). There are basically two counter-measures against this attack:

1. Mix the IV and the shared key using a hash function or
2. Discard the first 256 bytes of RC4's output.

There has been some disinformation in the news about the “flaws” of TKIP:

For now, TKIP is reasonably secure but it is also living on borrowed time since it still relies on the same RC4 algorithm that WEP relied on.

Actually, TKIP (WPA1) is not vulnerable: for each packet, the 48-bit IV is mixed with the 128-bit pairwise temporal key to create a 104-bit RC4 key, so there's no statistical correlation at all. Furthermore, WPA provides counter-measures against active attacks (traffic reinjection), includes a stronger message integrity code (michael), and has a very robust authentication protocol (the 4-way handshake). The only vulnerability so far is a dictionary attack, which fails if the passphrase is robust enough.

WPA2 (aka 802.11i) is exactly the same as WPA1, except that CCMP (AES in counter mode) is used instead of RC4 and HMAC-SHA1 is used instead of HMAC-MD5 for the EAPOL MIC. Bottom line, WPA2 is a bit better than WPA1, but neither are going to be cracked in the near future.

See the links page.

You may use the airdecap-ng program

There are two authentication modes for WEP:

• Open System Authentication: This is the default mode. All clients are accepted by the AP, and the key is never checked meaning association is always granted. However if your key is incorrect you won't be able to receive or send packets (because decryption will fail), so DHCP, ping etc. will timeout.
• Shared Key Authentication: The client has to encrypt a challenge before association is granted by the AP. This mode is flawed and leads to keystream recovery, so it's never enabled by default.

The NetGear Wireless Basics Manual has a good description of WEP Wireless Security including diagrams of the packet flows in its subsections.

You may use File → Merge… in Wireshark or Ethereal. Make sure to export in pcap format.

From the command line you may use the mergecap program to merge .cap files (part of the Wireshark/Ethereal package or the win32 distribution):

mergecap -F pcap test1.cap test2.cap test3.cap -w out.cap

It will merge test1.cap, test2.cap and test3.cap into out.cap

mergecap -F pcap *.cap -w out.cap

It will merge all the .cap files contained in the current folder into out.cap

You may use the ivstools program to merge .ivs files (part of aircrack-ng package)

You may use the ivstools program (part of aircrack-ng package)

Under Linux, simply setup the card in monitor mode with the airmon-ng script. Under Windows, Wireshark can capture 802.11 packets using AirPcap. Except in very rare cases, Ethereal cannot capture 802.11 packets under Windows.

Recent versions of Ethereal and Wireshark can decrypt WEP. Go to Edit → Preferences → Protocols → IEEE 802.11, select 1 in the “WEP key count” and enter your WEP key below.

Wireshark 0.99.5 and above can decrypt WPA as well. Go to Edit → Preferences → Protocols → IEEE 802.11, select “Enable decryption”, and fill in the key according to the instructions in the preferences window. You can also select “Decryption Keys…” from the wireless toolbar if it's displayed.

Many times in this forum and on the wiki we suggest using Wireshark to review packets. There are two books which are available specifically for learning how to use Wireshark in detail.

The good news is that they have made Chapter 6 of the “Wireshark & Ethereal Network Protocol Analyzer Toolkit” covering wireless packets available online in PDF format. Here is the link to Chapter 6. As well, see this section on the Wireshark Wiki.

The Wireshark display filter reference lists wlan (general 802.11), wlan_mgmt (802.11 management), wlancap (AVS capture header), wlancertextn (802.11 certificate extensions), and radiotap (radiotap header)

Note: It is not necessary to change the MAC address anymore to perform attacks; this can, in some cases, confuse the driver.

Under linux, the following information applies.

One method is:

ifconfig ath0 down
ifconfig ath0 hw ether 00:11:22:33:44:55
ifconfig ath0 up

Be aware that the example above does not work with every driver.

The easier way is to use the macchanger package. The documentation and download is at: macchanger.

If you are using mac80211 drivers and have a mon0 interface then:

 ifconfig mon0 down
 
 macchanger -a mon0
 Current MAC: 00:0f:b5:88:ac:82 (Netgear Inc)
 Faked MAC:   00:b0:80:3b:1e:1f (Mannesmann Ipulsys B.v.)
 
 ifconfig mon0 up
 macchanger -s mon0
 Current MAC: 00:b0:80:3b:1e:1f (Mannesmann Ipulsys B.v.)

IMPORTANT In the following scripts, newer versions of the madwifi-ng have deprecated (meaning discontinued) the “-bssid” option. If you get a warning to this effect, then use “-uniquebssid”.

Here are scripts which use the macchanger package and work well with madwifi-ng drivers:

Script 1 - Invoked with “macc.sh XX:XX:XX:XX:XX:XX”

 #!/bin/sh
 cardctl eject
 cardctl insert
 wlanconfig ath0 destroy
 ifconfig wifi0 up
 ifconfig wifi0 down
 macchanger wifi0 -m $1
 wlanconfig ath0 create wlandev wifi0 wlanmode monitor -bssid

Script 2 - For madwifi-ng driver devices

 #!/bin/sh
 # by darkAudax
 # Change the following variables to match your requirements
 FAKEMAC="00:14:6C:71:41:32"
 IFACE="ath0"
 WIFACE="wifi0"
 #
 # The interface is brought up and down twice otherwise
 # it causes a system exception and the system freezes
 #
 ifconfig $IFACE down
 wlanconfig $IFACE destroy
 wlanconfig $IFACE create wlandev $WIFACE wlanmode monitor -bssid
 ifconfig $IFACE up
 ifconfig $IFACE down
 macchanger $WIFACE -m $FAKEMAC
 wlanconfig $IFACE destroy
 wlanconfig $IFACE create wlandev $WIFACE wlanmode monitor -bssid
 ifconfig $IFACE up
 ifconfig $IFACE
 iwconfig
 echo " "
 echo "The wireless card MAC has been set to $FAKEMAC"
 echo " "

Script 3 - For madwifi-ng driver devices

 #!/bin/bash
 #
 # athmacchange.sh - Atheros MAC Changer
 # by brad a
 # foundstone
 #
 
 if [ -z "$1" ]; then
    echo Atheros MAC Changer
    echo -----------------------
    echo IMPORTANT: this assumes we want to change the MAC of wifi0
    echo " if you want to change the MAC of another wifi interface"
    echo " (i.e. wifi1, wifi2, etc...) change the script!"
    echo
    echo usage: $0 [mac]
    echo
    exit
 fi
    
 echo Atheros MAC Changer
 echo -------------------------
 echo -Destroying VAPs:
    
 for i in $( ls /proc/net/madwifi ); do
    wlanconfig $i destroy 2>&1 /dev/null
    echo -e "\t$i - destroyed"
 done
  
 echo -Downing wifi0
 ifconfig wifi0 down
 
 echo -Using macchanger to change MAC of wifi0
 macchanger -m $1 wifi0
 
 echo -Bringing wifi0 back up
 ifconfig wifi0 up
 
 echo -Bringing up one VAP in station mode
 wlanconfig ath create wlandev wifi0 wlanmode monitor -bssid > /dev/null
 
 echo -All done!
 echo -Confirm your settings:
 echo ------------------------------------------------------
 ifconfig wifi0
 echo ------------------------------------------------------

Madwifi-ng Notes: The madwifi site has a detailed documentation page on changing the MAC address under madwifi-ng: How can I change the MAC address of my card? Starting in r2435 of the madwifi-ng driver, they changed the default way in which new VAPs get their MAC address. When creating a new VAP with wlanconfig, you must specify “-bssid” to have it use the underlying MAC address. If you don't do this, then the new VAP gets a unique MAC. This will cause problems with various aircrack-ng commands.

Under Windows, you may use:

• macmakeup
• Technitium MAC Address Changer

Troubleshooting Tip: A normal MAC address looks like this: 00:09:5B:EC:EE:F2. The first half (00:09:5B) of each MAC address is the manufacturer. The second half (EC:EE:F2) is unique to each network card. Many access points will ignore invalid MAC addresses. So make sure to use a valid wireless card manufacturer code when you make up MAC addresses. Otherwise your packets may be ignored.

Read the Tutorial: Is My Wireless Card Compatible? tutorial. Then check the Compatible Cards page.

Yes, you can.

• You have to prefix those special characters with a “\”. This is called escaping a special character. Examples: with\'singlequote, with\“doublequote.
  
• You also need to handle the symbol ”&“ the same way. Example: “A&B”.
• You can use single quotes. Examples: 'with space', 'with”doublequote'.
  
• As well, you can use double quotes. Examples: “with space”, “with'singlequote”.
  

NOTE: If you enclose the AP name in single or double quotes, then you don't also need to escape special characters within the single or double quotes.

IMPORTANT EXCEPTION: If the AP name contains “!” then special care must be taken. The reason is that the bash interpreter thinks you want to repeat a previous command. Your options are:

• Use single quotes as in 'name!with!bang'.
• Escape the “!” as in name\!with\!bang.
• Use double quotes plus the escape as in “name\!with\!bang”

Sometimes the AP name contains leading or trailing spaces. These can be very hard to identify from the airodump-ng screen. Here are a few methods to deal with this situation:

• The airodump-ng text file includes the SSID (AP name) length. So you can compare the length in the text file to the count of visible characters. If the airodump-ng text file count is greater then you know that the SSID has leading or trailing spaces.
• Use wireshark to look at the beacon. Unless the SSID is hidden, the SSID is in quotes and you should be able to see leading/trailing spaces.
• The 1.0rc1 version of aireplay-ng will automatically pull the correct SSID from the beacon for you assuming it is not hidden. Simply omit the SSID parameter from aireplay-ng.

When captured through a wireless interface, 68 bytes is typical for arp packets originating from wireless clients. 86 bytes is typical for arp requests from wired clients.

On Ethernet, ARP packets when received are typically 60 bytes long. When this is then relayed by a wireless access point, they are 86 bytes. This is, of course, because of the wireless headers. If a wireless client sends an ARP, they are typically 42 bytes long and they become 68 when relayed by the AP.

You can try netdiscover or ARP tools

To determine the frequency that a channel uses (or vice versa), check out: Wifi Channels. Or check out Wikipedia List of WLAN Channels. This is a nice graphic showing the channel assignments and their overlap.

Here are some conversion links. Remember to put % in front of each hex character when going from hex to ascii.

• https://www.rapidtables.com/convert/number/hex-to-ascii.html
• http://www.mikezilla.com/exp0012.html

LatinSuD has developed a very useful tool - Javascript WEP Conversion Tool. It can perform a variety of WEP, ASCII and passphrase conversions.

See airpcap.

First, make sure you aren't using the orinoco driver. If the interface name is wlan0, then the driver is HostAP or wlan-ng. However if the interface name is eth0 or eth1, then the driver is orinoco and you must disable the driver. The easiest way to do this is to blacklist it in /etc/modprobe.d/blacklist.

Also, it can be a firmware problem. Old firmwares have trouble with test mode 0x0A (used by the HostAP / wlan-ng injection patches), so make sure yours is up to date (see Prism2 flashing for instructions). The recommended station firmware version is 1.7.4. If it doesn't work well (kismet or airodump-ng stalls after capturing a couple of packets), try STA 1.5.6 instead (either s1010506.hex for old Prism2 cards, or sf010506.hex for newer ones).

On a side note, test mode 0x0A is somewhat unstable with wlan-ng. If the card seems stuck, you will have to reset it, or use HostAP instead. Injection is currently broken on Prism2 USB devices with wlan-ng.

There are quite a few problems with some versions of the Linux 2.6 branch (especially before 2.6.11 was released) that will cause a kernel panic when injecting with madwifi. Also, on many 2.6 kernels enhanced RTC support is just broken. Thus, is it highly recommended to use either Linux 2.6.11.x or newer.

Problem: The wireless card behaves badly if the signal is too strong. If you are too close (1-2m) to the access point, you get high quality signal but actual transmission rates drop (down to 5-11Mbps or less). The net result is TCP throughput of about 600KB/s.

This is called antenna and receiver saturation. The signal coming in to the preamplifier is too strong and clips the input of the amplifier, causing signal degradation. This is a normal phenomenon with most 802.11 hardware.

So, is it a driver problem or is it my network hardware?

Neither, really. It's a physics problem. The only solution is to either decrease transmission power, use an antenna with a lower gain factor, or move the access point farther away from the station. You should use wired ethernet when you're close to the access point. If you don't want or you don't have a wire, you can also decrease output power of your Access point or your card.

See the wiki home page for links to the relevant sub-pages.

This usually happens because the linux headers don't match your current running kernel. In this situation, grab the kernel sources or just recompile a fresh kernel, install it and reboot. Then, try again compiling the driver. See this HOWTO for more details about kernel compilation.

Double check that your device name is correct and that you haven't forgotten a parameter on the command line.

When using linux-wlan-ng driver, be sure to enable the interface first with airmon-ng.

Some drivers require a firmware to be loaded (b43, prism54, zd1211rw, …). The driver typically loads the firmware itself when started.
In this case, the driver didn't find it because the firmware was not in the right place or is missing from the computer. To find the firmware's correct location, read the driver documentation.

See Airmon-ng arpreplay functions freeze with rt2x00 & rt2570 1.4.0 (wusb54g) in the Forum.

Yes, aircrack-ng suite successfully been run under VMware. One thing about doing VMware, you can't use PCMCIA or PCI cards. You can ONLY use compatible USB wireless cards. Some limited additional information is available here:

• VMWare tips and tricks

Kali is available as a virtual machine.

Various tips

Running the Windows GUI gives an error message similar to “the application failed to initialize properly (0xc0000135). Click on OK to terminate the application”. To correct this, ensure you have the Microsoft .NET framework 2.0 installed.

Or even to eth2 or from wlan0 to wlan1 or … You know the symptoms mean if you suffer this problem. This happens when you change your MAC and UDEV thinks it has detected a new network card. UDEV keeps track of this so that your nwc-naming keeps mixed up even after a reboot.

Solution: Disable this function in UDEV

Open /etc/udev/persistent-net-generator.rules in your preferred text editor

Search for

 KERNEL=="eth*|ath*|wlan*|ra*|sta*", DRIVERS=="?*",\
 	IMPORT{program}="write_net_rules $attr{address}"

and change it to

 #KERNEL=="eth*|ath*|wlan*|ra*|sta*", DRIVERS=="?*",\
 #	IMPORT{program}="write_net_rules $attr{address}"

Save and close.

Open /etc/udev/rules.d/z25_persistent-net.rules in your preferred text editor (“z25_” may be something different on your system).

Search for the lines concerning your nwc and delete or just disable them by inserting a leading “#”.

Reboot and everything should be back to normal and stay there.

Note: If you update udev to a newer revision you may have to do this again.

A normal MAC address looks like this: 00:09:5B:EC:EE:F2. It is composed of six octets. The first half (00:09:5B) of each MAC address is known as the Organizationally Unique Identifier (OUI). Simply put, it is the card manufacturer. The second half (EC:EE:F2) is known as the extension identifier and is unique to each network card within the specific OUI. Many access points will ignore MAC addresses with invalid OUIs. So make sure you use a valid OUI code when you make up MAC addresses. Otherwise, your packets may be ignored by the Access Point. The current list of OUIs may be found here.

Make sure that that the last bit of first octet is 0. This corresponds to unicast addresses. If it is set to 1, this indicates a group address, which is normally exclusively used by multicast traffic. MAC addresses with a source set to multicast are invalid and will be dropped.

• Examples of valid OUIs: 00:1B:23, 08:14:43, AA:00:04 because 0, 8 and A are even
• Examples of invalid OUIs: 01:1B:23, 03:23:32

In particular, it is recommended that the first octet is 00.

The address resolution protocol (ARP) is explained in more detail here.

The aircrack-ng suite has limited Mac OS X support. Currently it only supports the following tools: aircrack-ng, packetforge-ng, ivstools and makeivs. Any program which requires opening a wireless interface is not supported.

RSSI means Received Signal Strength Indication. RSSI is a measurement of the received radio signal strength. It is the received signal strength in a wireless environment, in arbitrary units.

For more information, see https://en.wikipedia.org/wiki/RSSI

Every packet is sent with a preamble, which is just a known pattern of bits at the beginning of the packet so that the receiver can sync up and be ready for the real data. This preamble must be sent at the basic rate (1 Mbps), according to the official standard. But there are two different kinds of preambles, short and long. The long preamble has a field size of 128 bits, while the short preamble is only 56 bits.

No, this is a false assumption in most situations.

In a home environment, the best output power is not always the maximum. In most situations, 30mw is enough. However, if you are a long distance from the AP, then yes, maximum output power is the best.

No, amplifiers are not a very good idea because:

1. Amplifiers also amplify noise and that's not a good thing for link quality
2. With high amplification, you could get a headache

You are much better off purchasing a good antenna with high gain.

Most cards have 100mW when combined with the antenna (2dBi antenna).

In 802.11a and 802.11g, the output power is 30mW due to modulation (it's a bit harder to use OFDM than CCK)

No, the transmit power is not linked with receiving at all. For receiving, you should check the receive sensitivity of your card. As well, you are much better off purchasing a good antenna with high gain.

You should see Antenna help, Selecting a Wifi Antenna.

See airmon-ng documentation.

Use iwconfig to view the current speed setting of the wireless card. 1, 2, 5.5 and 11Mbit are 802.11b, 6, 9, 12, 18, 24, 36, 48, 54Mbit are 802.11a/g. Anything above 54Mbit is 802.11n.

If you have a very new USB device, sometimes the device ID has not been included in the driver. The following article describes how to do this for a specific driver. The technique can be used for all USB drivers.

Adding new device IDs to zd1211rw

You receive one or both of the following errors:

 error creating tap interface: Permission denied
 error opening tap device: Permission denied

This is caused by SELinux (Security Enhanced Linux) preventing the interface from starting. To resolve, disable SELinux. See the support forums for your particular linux to determine how to do this.

By default, in settings, stty rows and columns are set to 0. Here are the settings:

• stty columns 86
• stty rows 39

Aircrack-ng is “free software”; you can download it without paying any license fee. The version of Aircrack-ng you download isn't a “demo” version, with limitations not present in a “full” version; it is the full version. The license under which Aircrack-ng is issued is mostly the GNU General Public License version 2. See the GNU GPL FAQ for some more information.

You may also want to check out the OpenSSL license included in our source code download.

That depends. Did they provide any sort of value-added product or service, such as installation support, installation media, training, trace file analysis, or funky-colored socks? Probably not. Aircrack-ng is available for anyone to download, absolutely free, at any time. Paying for a copy implies that you should get something for your money.

Yes, if, for example, you mean “I work for a commercial organization; can I use Aircrack-ng to capture and asses WiFi network security in our company's networks or in our customer's networks?”

If you mean “Can I use Aircrack-ng as part of my commercial product?”, see the next entry in the FAQ.

As noted, Aircrack-ng is licensed under the GNU General Public License, version 2. The GPL imposes conditions on your use of GPL'ed code in your own products; you cannot, for example, make a “derived work” from Aircrack-ng, by making modifications to it, and then sell the resulting derived work and not allow recipients to give away the resulting work. You must also make the changes you've made to the Aircrack-ng source available to all recipients of your modified version; those changes must also be licensed under the terms of the GPL. See the GPL FAQ for more details; in particular, note the answer to the question about modifying a GPLed program and selling it commercially, and the question about linking GPLed code with other code to make a proprietary program. You can combine a GPLed program such as Aircrack-ng and a commercial program as long as they communicate “at arm's length”, as per this item in the GPL FAQ.

We recommend keeping Aircrack-ng and your product completely separate.

You may also want to check out the OpenSSL license included in our source code download.

Yes. As long as you take the screenshots yourself. If you are using someone else's, you may need to obtain their authorization to use them.

A hard block usually is a physical switch on the computer. It can either be a flip switch on the side of the computer, a key combination to press on the keyboard or a setting to enable in the BIOS.

In some cases, if wireless was disabled before Windows was powered off, it will appear like a hard block and the trick is to enable wireless in Windows then reboot.

TL;DR: even if it sounds bad, don't worry about it.

If a firmware is missing, then your card won't work at all: no interface, scanning or any other function. Firmware may have issues/bugs but that's a different story.

On desktop/laptop cards, the above mentioned file is stored in a dedicated EEPROM on the card itself, so it's not needed. That data is typically only needed on embedded devices, such as routers, or AP, that are lacking the EEPROM, and in that case, it is stored on the filesystem. The reason behind it is cheaper to store it, than adding extra components.

The driver doesn't have any way of knowing if the card has it or not, so it is displaying the message anyway.

The “-p” parameter controls the amount of threads used for bruteforcing the passphrase; Aircrack-ng has other tasks using the CPU as well.

Prior to this message, it can be seen that the device connected on a USB port with xhci_hcd, indicating USB 3.0.

This issue happens mostly in virtual machines, when the USB port is set to 3.0. To work around the issue, power off the virtual machine, edit USB settings of the VM and set it to 2.0.

The following may be present in dmesg instead:

xhci_hcd 0000:00:14.0: WARN Cannot submit Set TR Deq Ptr
xhci_hcd 0000:00:14.0: A Set TR Deq Ptr command is pending.

For mt76x0u, you may see any of the following messages as well:

mt76x0u 1-1:1.0: rx urb failed: -71
mt7601u 1-2:1.0: Error: mt7601u_mcu_wait_resp timed out
mt7601u 1-2:1.0: Vendor request req:07 off:0080 failed:-71
mt7601u: probe of 1-2:1.0 failed with error -110

And for rt2800usb:

rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0404 with error -71
rt2800_wait_csr_ready: Error - Unstable hardware
rt2800usb_set_device_state: Error - Device failed to enter state 4 (-5)

This bug affects kernels >= 4.20. It happens mostly when connecting certain USB 2.0 devices on a USB 3.0 port but it can happen with USB 3.0 devices as well. It isn't WiFi adapter's driver's fault, but an issue in the USB subsystem code.

Until the bug is fixed, the workaround for USB 2.0 devices is to plug the device on a USB 2.0 port. If you are using a virtual machine, power off the virtual machine, and change USB port settings to 2.0.

airmon-ng is a Linux/FreeBSD script only. There is no version for Windows, MacOS, or other OS at this time.

We are assuming it used to work in the past, and that you have checked that network managers were killed prior to putting the card in monitor mode.

The next step would be to look into 'dmesg' to see if the driver outputs any error or warnings. If the card is USB, clearing it using 'dmesg -c' before plugging the adapter may help, by decreasing the amount of messages you have to go through.

No.