Reported by anonymous on 30 Dec 2006 11:11 UTC

aircrack does not compile on my Arch box.
Arch is up to date. (I use the current, extra and community repos....)

kernel is a 2.6.19

gcc version: gcc (GCC) 4.1.2 20061215 (prerelease)
I tried the PKGBUILD and just make.

this is the error-message from make:

gcc -g -W -Wall -O3 -D_FILE_OFFSET_BITS=64 src/aircrack-ng.c \
 src/crypto.c src/sha1-mmx.S src/common.c -o aircrack-ng -lpthread
gcc -g -W -Wall -O3 -D_FILE_OFFSET_BITS=64 src/airdecap-ng.c \
 src/crypto.c src/common.c src/crc.c -o airdecap-ng
gcc -g -W -Wall -O3 -D_FILE_OFFSET_BITS=64 src/packetforge-ng.c \
 src/common.c src/crc.c -o packetforge-ng
gcc -g -W -Wall -O3 -D_FILE_OFFSET_BITS=64 src/aireplay-ng.c \
 src/common.c src/crc.c -o aireplay-ng
In file included from src/aireplay-ng.c:34:
/usr/include/linux/wireless.h:885: error: 'IFNAMSIZ' undeclared \
 here (not in a function)
src/aireplay-ng.c: In function 'openraw':
src/aireplay-ng.c:2189: error: storage size of 'ifr' isn't known
src/aireplay-ng.c:2189: warning: unused variable 'ifr'
make: *** [aireplay-ng] Error 1

Reported by hirte on 24 Dec 2006 18:41 UTC

When specifying a prga where the 4th byte isn't 00-03 and/or the file extension is different from .xor then there should be a warning to specify a PRGA file from --chopchop or --fragment.

Reported by misterx on 22 Dec 2006 22:10 UTC

Make aircrack-ng being able to use coWPAtty WPA/WPA2 tables

Reported by misterx on 11 Dec 2006 22:59 UTC

Add support for AirPcap adapter on Windows

Reported by latinsud on 23 Dec 2006 19:36 UTC

Aireplay-ng switch "-j" should not require an argument, but it currently does.

The current getopt string:

"b:d:s:m:n:u:v:t:f:g:w:x:p:a:c:h:e:j:i:r:k:l:y:0:1:2345",

The proposed one:

"b:d:s:m:n:u:v:t:f:g:w:x:p:a:c:h:e:ji:r:k:l:y:0:1:2345",

Posted in forum. http://tinyshell.be/aircrackng/forum/index.php?topic=903.

Reported by misterx on 7 Jan 2007 20:38 UTC

from darkAudax:

Since there are now multiple ways to get xor files (chopchop, fragmentation), why not have an option to read in the xor file and create a valid keep encrypted keep alive packet. This would further ensure a solid "connection" to the access point.

Reported by darkAudax on 8 Jan 2007 22:03 UTC

This enhancement is for a future generation of the fragmentation attack. This write-up is to start people thinking about it and there is no expectation that the implementation will be any time soon.

The current frag attack is oriented towards access points. As access points become stronger from a security point of view, the weak link is the wireless client itself. The wireless client tends to have very few controls or smarts to prevent attacks. So with this in mind...

Why not modify the frag attack so packets can optionally be sent to the wireless client instead of the access point. There is an existing "-j" flag in aireplay-ng to "-j : arpreplay attack : inject FromDS pkts". I don't believe this gets applied to the packets being generated for the frag attack.

For this to work, both the FromDS and ToDS flags would need to get set correctly. As well, you would need to know the IP address of the client so the arp could be directed at the client directly and it would respond to the arp request. Makes it harder but doable.

The other unknown is if a wireless client would reassemble fragmented packets. My thought would be yes but I don't know that for sure.

Although there are some unknowns, if it could all be made to work, it would be a great new attack vector.

d.

Reported by hirte on 24 Dec 2006 18:43 UTC

As most of the time the ToDS bit should be set, it should be the standard setting for generating a packet.

Reported by misterx on 15 Dec 2006 23:17 UTC

Create a new format that will replace IVs file with the following advantages:

• Contain the ESSID (or at least its lenght if it wasn't found)
• Can handle both WEP (IVs and enough data for PTW) or WPA (handshake). And a file can contain both format (I mean one or more WEP network and one or more WPA network) at the same time
• Versionned, so that it can be easily updated

Reported by misterx on 15 Dec 2006 23:12 UTC

Add 2 options to ivstools:

• Split in several files containing each the same number of IVs
• Merge IVS from different BSSID (AP MAC address)

Reported by misterx on 7 Jan 2007 13:17 UTC

Taken from the forum ( http://tinyshell.be/aircrackng/forum/index.php?topic=14.msg5122#msg5122 ) :

The fragmentation attack would not work consistently.

The cause is that if MAC address of the spoofed packets does not match the MAC address of the card in the PC then they are malformed. The only way to successfully have the fragmentation attack work is to first change the MAC address of the card to match the spoofed MAC address. The details follow. To simplify the analysis, I changed aireplay-ng to only do one round instead of ten.

The first packet capture "frag-different-mac.cap" is a capture when the mac address is different. You will see that the fragmented packet is properly generated. IE 12 fragments numbered 0 to 11. However, notice that the sequence number in the frame control is different for each fragment instead of being the same. So the access point does not know to assemble the fragments into a single packet.

Here is what it looks like. Notice also that there is a false positive "Got ANSWER packet!!". I am not sure why this happens.

# aireplay-ng -5 ath0 -b 00:14:6C:7E:40:80 -h 00:09:5B:EC:EE:F2 -l 192.168.55.15
Madwifi: 1  Madwifi-ng: 1
Waiting for a data packet...
Data packet found!
Sending fragmented packet
Got ANSWER packet!!
Trying to get 408 bytes of a keystream
No answer, repeating...
Still nothing, trying another packet...

Now I change the mac address of the wireless card to match the spoofed mac address.

The second packet capture "frag-same-mac.cap" is a capture when the mac address is the same. You will see that the fragmented packet is properly generated. IE 12 fragments numbered 0 to 11. And now the sequence number in the frame control is the same for each fragment. Bingo, the access point knows the fragments belong to the same packet and can assemble it.

Here is the successful output:

# aireplay-ng -5 ath0 -b 00:14:6C:7E:40:80 -h 00:09:5B:EC:EE:F2 -l 192.168.55.15
Madwifi: 1  Madwifi-ng: 1
Waiting for a data packet...
Data packet found!
Sending fragmented packet
Got RELAYED packet!!
Thats our ARP packet!
Trying to get 408 bytes of a keystream
Got RELAYED packet!!
Thats our ARP packet!
Trying to get 1500 bytes of a keystream
Got RELAYED packet!!
Now you can build a packet with packetforge-ng out of that 1500 bytes keystream

Proof also comes from a sniff from a system on the ethernet. You can see that the arp was successfully generated.

tcpdump -n arp
16:50:28.397796 arp who-has 255.255.255.255 tell 192.168.55.15

So now the question comes... What causes this problem? I suspect it is the madwifi-ng drivers. I will let you and the other gurus decide on the root cause. Makes me wonder if new madwifi-ng drivers would fix the problem. In the meantime, we have a workaround.

The other question is if this same problem occurs with other drivers.

So folks, here is what to look for if you are using Atheros/madwifi-ng and your fragmentation attack is not working. First, change your card mac address to the one you will be spoofing. Second, capture your attack traffic. Then confirm that the following is true:

You should see 12 fragments numbered 0 through 11. Each fragment must have the same sequence number and initialization vector. The initialization vector should match the one on the packet which triggered the fragmentation attack.

Reported by misterx on 2 Jan 2007 21:36 UTC

There's 2/3 errors with airmon-ng:

• First it should check if the user is root to avoid SIOCSIFFLAGS (Permission denied)
• wlanconfig: ioctl: Operation not permitted (it could be linked to the first error)
• [: 417: ==: unexpected operator

Here is the output:

# airmon-ng stop ath0


Interface	Chipset		Driver

SIOCSIFFLAGS: Permission denied
wifi0		Atheros		madwifi-ng
[: 417: ==: unexpected operator
eth1		Centrino b/g	ipw3945
[: 417: ==: unexpected operator
ath0		Atheros		madwifi-ng VAP (parent: wifi0)wlanconfig: ioctl (VAP destroyed)


# airmon-ng start wifi0


Interface	Chipset		Driver

SIOCSIFFLAGS: Permission denied
wifi0		Atheros		madwifi-ngwlanconfig: ioctl: Operation not permitted
Error : unrecognised wireless request 10

[: 417: ==: unexpected operator
eth1		Centrino b/g	ipw3945
[: 417: ==: unexpected operator
ath0		Atheros		madwifi-ng VAP (parent: wifi0)

Reported by misterx on 12 Dec 2006 21:41 UTC

Close open handles on files in packetforge-ng

Reported by Ace on 5 Jan 2007 23:38 UTC

It would be very nice if someone could change this:

• the *.txt is now a binary file (not so bad, but can't edit it for testing)
• if airodump can't get specific informations, it writes nothing to the file instead of a blank (" ")

e.g. :

BSSID, First time seen, Last time seen, channel, Speed, Privacy, Cipher, Authentication, Power, # beacons, # IV, LAN IP, ID-length, ESSID, Key
00:03:C9:B5:4C:29, 2007-01-05 12:02:17, 2007-01-05 12:02:21, 11,  48, OPN '''!,,,'''   6,       31,        0,   0.  0.  0.  0,   8,         ,

should be :

BSSID, First time seen, Last time seen, channel, Speed, Privacy, Cipher, Authentication, Power, # beacons, # IV, LAN IP, ID-length, ESSID, Key
00:03:C9:B5:4C:29, 2007-01-05 12:02:17, 2007-01-05 12:02:21, 11,  48, OPN ''', , ,'''   6,       31,        0,   0.  0.  0.  0,   8,         ,

link to forum post: http://tinyshell.be/aircrackng/forum/index.php?topic=982.0

Reported by gandalf on 11 Dec 2006 22:01 UTC

Debian Bug Report #390673

The /usr/sbin/airmon-ng script completly breaks if /bin/sh is dash. In fact, the entire script is full of bashisms.

The solution is to either use /bin/bash, or fix all of the bashisms.

Reported by b cisek on 12 Jan 2007 18:10 UTC

There is a problem with airodump-ng (from svn) when I try to run it on Orinoco/Hermes I.

Config:

Linux kernel 2.6.18.2

orinoco drivers http: www.kismetwireless.net /code/ orinoco-0.13-dragorn-2.6.17.tar.gz

eth2 Available private ioctls :

      force_reset      (8BE0) : set   0       & get   0

      card_reset       (8BE1) : set   0       & get   0

      set_port3        (8BE2) : set   1 int   & get   0

      get_port3        (8BE3) : set   0       & get   1 int

      set_preamble     (8BE4) : set   1 int   & get   0

      get_preamble     (8BE5) : set   0       & get   1 int

      set_ibssport     (8BE6) : set   1 int   & get   0

      get_ibssport     (8BE7) : set   0       & get   1 int

      monitor          (8BE8) : set   2 int   & get   0

      dump_recs        (8BFF) : set   0       & get   0

Error message:

mustafa:~# airodump-ng --channel 2 --ivs -w wep eth2

ioctl(SIOCSIWMODE) failed: Invalid argument

Error setting monitor mode on eth2

thanks :)

Reported by misterx on 22 Dec 2006 22:19 UTC

In read_thread() in aircrack-ng.c, there is a possibility of a deadlock at the mutex lock (mx_apl) due to a continue which doesn't unlock the mutex.

This manifests itself as a hang when reading from a capture file (which contains a packet formed in such a way that it triggers the problem). The output looks like this:

aircrack-ng file.cap
Opening file.cap
Reading packets, please wait...

A possible fix:

--- aircrack-ng-0.6/src/aircrack-ng.c   2006-06-22 20:53:57.000000000 -0700
+++ aircrack-ng-0.6_modified/src/aircrack-ng.c  2006-07-04 20:54:47.000000000 -0700
@@ -845,7 +845,7 @@
                ap_cur->crypt = 3;               /* set WPA */

                if( st_cur == NULL )
-                       continue;
+                       goto unlock_mx_apl;

                /* frame 1: Pairwise == 1, Install == 0, Ack == 1, MIC == 0 */

See http://tinyshell.be/aircrackng/forum/index.php?topic=322.0

Reported by misterx on 16 Dec 2006 13:35 UTC

Replace airmon-ng by wifidetect (by Zero Chaos) and fix known limitations:

• if madwifi-ng detection fails it should use madwifi-old before continuing
• if you have multiple madwifi-ng devices it may get ugly (not sure)
• if you have madwifi-ng and you run monitor twice it will loop creating monitor VAPs

Add support for detecting other drivers:

• Realtek 8187
• Latest ralink chipsets
• Other less used drivers (admtek, atmel_usb, legacy cisco, ...)
• ...

Reported by hirte on 3 Jan 2007 21:36 UTC

Define

-D_DEVEL="`cat .svn/entries | grep revision | sed 's/.*revision=\"\(.*\)\".*/\1/'`"

as an OPTFLAGS option in the Makefile and delete "#define _DEVEL 0" in version.h

'''We have to reverse that for the stable versions! '''

But using that method gives us way better control of hunting down bugs in svn revisions, as users can post us the exact version from the command they used ( | grep dev) , instead of trusting their intuition for using "the newest checkout" ...

Personally i don't like this rather complex command to be used as an option for gcc, because of the high failure potential it involves. So I'd like to read some alternatives as a response to this ticket ;).

Reported by misterx on 5 Jan 2007 22:07 UTC

make error message (line 20 of sha1-mmx):

gcc -g -W -Wall -O3 -D_FILE_OFFSET_BITS=64 src/aircrack-ng.c src/crypto.c \
  src/sha1-mmx.S src/common.c -o aircrack-ng -lpthread
src/sha1-mmx.S:20:Alignment too large: 15. assumed.
/usr/bin/ld: alignment (0x8000) of section (__DATA,__data) greater than the segment alignment (0x1000)
collect2: ld returned 1 exit status
make: *** [aircrack-ng] Error 1

Reported by misterx on 16 Dec 2006 15:51 UTC

Timeline and sources are sometimes not updated. At the moment, we are at revision 13 but timeline and sources only show revision 11.

Reported by hirte on 17 Dec 2006 16:35 UTC

make --chopchop and --fragment in aireplay-ng work with non IP LLC/SNAP headers

Reported by misterx on 16 Dec 2006 12:33 UTC

Many access points (e.g. Linksys) send out spanning tree BPDU packets every second or so. These packets are WEP encrypted and thus contribute to the IV data used for cracking. There is only one small problem: The first two bytes of these packets (before encryption) are not 0xAA, but 0x42.

Currently, aircrack-ng sort of ignores this. Given that these STP packets are usually only a small fraction of the total number of packets with IV data, the incorrect assumption about the first two bytes only contributes a little bit of statistical noise to the analysis, but with enough packets, it doesn't make too much of a difference. However, what this means is that there is a bit of room for improvement to make the analysis more accurate with less IV data.

The STP packets can be easily identified, because the Destination Address in the packet header will be 01:80:C2:00:00:00 (which is the All STP bridges multicast MAC address). So for these packets, we can have airodump-ng modify the IV data it saves to the .ivs file as follows:

if (Destination Address of packet == 01:80:C2:00:00:00)
write 3 byte IV to .ivs file

outbyte1 = (outbyte1 XOR 0x42) XOR 0xAA

outbyte2 = (outbyte2 XOR 0x42) XOR 0xAA

write outbyte1, outbyte2 to .ivs file

What we are doing here is xoring the output bytes with 0x42 to recover the keystream and then xoring that with 0xAA so that when aircrack-ng applies the FMS and KoreK attacks to the (IV, output byte) set, the assumption that the plaintext output bytes before encryption == 0xAA will be correct (even though in the original packet, this assumption would have been incorrect).

This should help remove some false positives/negatives and make the analysis more accurate.

There's also issues when chopchoping STP packets.

Reported by gandalf on 11 Dec 2006 22:11 UTC

Debian Bug Report #390142

"usefull" -> "useful"

Reported by hirte on 1 Jan 2007 15:22 UTC

Create a new file format, which contains all recovered keystreams. Build a tool (or include in aireplay as attack -6?), that'll generate keystreams and fill the database. Support for this db has to be written for packetforge-ng, airtun-ng and aireplay-ng (for all tools, which are using a keystream). These keystreams can be used in a way that we evade WIDS. Another example is airtun-ng, which could en-/decrypt (with a more or less complete keyspace) and thus using a network without cracking the key.

Reported by misterx on 31 Dec 2006 23:43 UTC

Lets say we have two workstations:

Ethernet workstation
IP: 192.168.55.51
MAC: 00:40:F4:77:F0:9B

Wireless workstation
IP: 192.168.55.109
MAC: 00:0F:B5:46:11:19

I want to create an ARP request packet from the ethernet workstation going to the wireless workstation.

The ARP request says "Who has 192.168.55.109? Tell 192.168.55.51".

So in my mind:

• Source IP in this case is 192.168.55.51 since this is where we want the packet returned.
• Destination IP in this case is 192.168.55.109 since this workstation will be receiving the packet and responding.

IE:

-k <ip[: set Source      IP [Port](:port]>)
-l <ip[: set Destination IP [Port](:port]>)

-k 192.168.55.51
-l 192.168.55.109

However to get the desired ARP packet, you need to reverse the addresses. The following command successfully generates the packet we want. You notice the sending and receiving IPs are reversed.

packetforge-ng --arp -a 00:14:6C:7E:40:80 -c 00:0F:B5:46:11:19
-h 00:40:F4:77:F0:9B -j -o -k 192.168.55.109 -l 192.168.55.51
-y replay_dec-1231-133021.xor -w arpforge.cap

tcpdump -n -vvv -e -s0 -r arpforge.cap           
reading from file arpforge.cap, link-type IEEE802_11 (802.11)
13:32:06.523444 WEP Encrypted 258us DA:Broadcast BSSID:00:14:6c:7e:40:80 SA:00:40:f4:77:f0:9b Data IV:162 Pad 0 KeyID 0

So I believe there is a bug in packetforge-ng whereby it reverses the addresses in the specific case above.

(Taken from the forum: http://tinyshell.be/aircrackng/forum/index.php?topic=986.0 )

Reported by misterx on 22 Dec 2006 21:35 UTC

Be able to specify the key space when cracking.
It can be ASCII chars or hexadecimal values.
For example: --keyspace ABCDEFGHIJKL

BTW, all options restricting key space should be grouped into one option (with an argument telling which predefined key space to use.

Reported by misterx on 21 Dec 2006 18:10 UTC

When merging multiple IVs files, ivstools should show the number of dupe IV so that the user won't ask where went all IVs. See http://tinyshell.be/aircrackng/forum/index.php?topic=863.0

Reported by misterx on 22 Dec 2006 21:43 UTC

In some cases, it's not possible to crack a key in one step, so it could be useful that aircrack-ng saves its current state and then being able to continue where it was stopped.

A state file should be created (or maybe the current key tested (or the state of the votes).

Remark: This will only work for a file that didn't change (no more IVs added/removed)

Reported by misterx on 22 Dec 2006 22:28 UTC

makeivs should be able to create IVs files for different key length, from 64 bit up to 512 bit

Reported by gandalf on 11 Dec 2006 22:13 UTC

Debian Bug Report #400775

aircrack-ng does not work when the wireless network has 802.11e QOS enabled;
the reason is an packet offset error in aircrack-ng.c, a simple patch is attached.

Reported by gandalf on 11 Dec 2006 21:49 UTC

Debian Bug Report #393540.

"only record" --> "only records"

Reported by gandalf on 11 Dec 2006 22:09 UTC

Debian Bug Report #399674

airdecap-ng fails to decrypt wep packets.

Function check_crc_buf() was modified not taking into account the way
the variable "buf" was used.

A solution is: at src/crc.c:22 (right before return), insert a: buf+=len

This was reported by user "!LatinSud" via forum at:
http://tinyshell.be/aircrackng/forum/index.php?topic=771.0

Confirmed that wep decrypt now works after recompiling package with
above change.

Reported by misterx on 16 Dec 2006 20:54 UTC

Update aireplay-ng manpage for the new --fragment option

Reported by misterx on 18 Dec 2006 21:24 UTC

• Aireplay should be able to choose IV from a pool (when ringbuffer is big enough or unlimited) that hasn't been used in last X packets
• Ghosting (tx power): by changing tx power of the card while injecting, we can evade location tracking. If you turn the radio's power up and down every few ms, the trackers will have a much harder time finding you (basicly you will hop all over the place depending on sensor position). At least madwifi can do it.
• Ghosting (speed/modulation): change speed every few ms, not a fantastic evasion technique but it may cause more location tracking oddity. Note that tx power levels can only be set at certain speeds (lower speed means higher tx power allowed).
• 802.11 allows you to fragment each packet into as many as 16 pieces. It would be nice if we could use fragmentated packets in every aireplay-ng attack.

Reported by cygeus on 4 Jan 2007 20:54 UTC

In 37a05c1 INSTALL was renamed to INSTALLING. so the Makefiles need to be changed accordingly:

old:

DOCFILES        = ChangeLog INSTALL README LICENSE AUTHORS VERSION

new:

DOCFILES        = ChangeLog INSTALLING README LICENSE AUTHORS VERSION

Reported by misterx on 6 Jan 2007 23:40 UTC

Taken from the forum ( http://tinyshell.be/aircrackng/forum/index.php?topic=1014.0 ):

I have always had major problems using "aireplay -1" fake authentication with my access point. When you run the command (with the appropriate parameters), it would get all kinds of variations: connected then get a disassociate packets, athenticate but can't associate, and on and on. Sometimes it would never complete successfully or sometimes take 5 to 8 minutes to be successful.

I finally got fed up and did some experiments. One thing that I noticed is that the standard fake authentication sends multiple authentication and associate requests out. My theory was that this was confusing the access point. So I modified aireplay to only send 1 packet of each instead of multiple.

Bingo! Aireplay consistently does fake authentication on the first try.

So this same problem likely comes up with other access points and certainly all the access points of the same brand. So here are my suggestions:

• Provide an option to override the default built into the program. This way we can try different numbers of packets. Maybe different numbers work better on certain APs. Certainly the quantity of 1 is required on my brand.

• Provide an option to overide the default time between keep alive packets. The default is currently 15 seconds. Personnally I like being able to send them every second. This way you know for sure you are still associated with the AP. If you become disassociated then you get know immediately.

Reported by misterx on 22 Dec 2006 22:13 UTC

Make aircrack-ng being able to distribute cracking of a key more or less like it does for SMP computer.

This should be done for 2.0 or 2.1 release (the server will be the "coordinator").

Reported by misterx on 23 Dec 2006 21:56 UTC

Write a manpage for airtun-ng

Reported by misterx on 22 Dec 2006 22:23 UTC

If a password in the dictionary you specify is too long (more than 63 chars), it causes aircrack-ng to core dump.

Reported by CValentine on 10 Jan 2007 18:50 UTC

Aireplay-ng keeps complaining about the interface MAC not matching the specified one during an aireplay-ng -3 attack. It's always listing the MAC as being set to 00:00:00:00:00:00 no matter if the mac is the card's original or been changed by macchanger. Via ifconfig the MAC is always correctly shown as set to the one requested though.

System is Ubuntu Edgy on a Centrino, Aircrack-ng SVN, patched IPW2200 v1.2.1 (and lower ones)

Reported by misterx on 29 Dec 2006 18:05 UTC

It seems like the packets being returned are 26 bytes in length. That is: frame control (2 bytes), duration id (2 bytes), 3 mac addresses (18 bytes), CRC (4 bytes). In other words, there is no actual data being returned. This is happening on the authentication request.

I am not sure if this is the fault of aireplay-ng when it sends the authentication request or reads the response, the fault of the madwifi driver when it sends or receives, or due to the specifics of the routers. It doesn't seem to happen with all routers, but most.

This is the extent to which I can help with this I think. Hopefully someone who can do more finds it useful. Below are a couple of packets in hex.

B0 - 08 - 3A - 01 - 00 - 11 - 22 - 33 - 44 - 55 - 00 - 0B - 23 - EB - D4 - F2 - 00 - 0B - 23 - EB - D4 - F2 - 80 - 07 - 00 - 00
B0 - 08 - 3A - 01 - 00 - 11 - 22 - 33 - 44 - 55 - 00 - 0B - 23 - EB - D4 - F2 - 00 - 0B - 23 - EB - D4 - F2 - 90 - 07 - 00 - 00
B0 - 08 - 3A - 01 - 00 - 13 - 02 - A4 - 21 - 95 - 00 - 13 - 46 - FC - 80 - BC - 00 - 13 - 46 - FC - 80 - BC - 70 - 39 - 00 - 00
B0 - 00 - 3A - 01 - 00 - 13 - 02 - A4 - 21 - 95 - 00 - 13 - 46 - FC - 80 - BC - 00 - 13 - 46 - FC - 80 - BC - 90 - 39 - 00 - 00

(Taken from the forum)

Reported by latinsud on 23 Dec 2006 19:29 UTC

Airmon-ng has a list of invalid ipw2200 driver versions. This list is not currently correct.

Current code is:

if { echo "$MODINFO" | grep -E '^1\.0\.(0|1|2|3)$|^1\.[; }
...
if { echo "$MODINFO" | grep -E '^1\.0\.(5|7|8|11)$|^1\.[1-9](1-9]')' ; }

This blacklists current working version, 1.2.0, as well as future versions. I don't remember the whole versioning history of the driver, but iirc it'd be safe to assume that version 1.1.1 and higher worked fine. So i suggest:

if { echo "$MODINFO" | grep -E '^1\.0\.(0|1|2|3)$' ; }
...
if { echo "$MODINFO" | grep -E '^1\.0\.(5|7|8|11)$' ; }

There's also an interesting feature of driver, starting from version 1.1.2, that appends a list of capabilities to version, like: 1.2.0dmprq. The 'm' indicates that support for monitor mode was compiled in.

Previously reported in forum
http://tinyshell.be/aircrackng/forum/index.php?topic=685.0

Reported by gandalf on 11 Dec 2006 22:05 UTC

Debian Bug Report #390143

airmon-ng prints a usage message even when the syntax is correct, which is confusing.

I spent a few minutes trying to find a non-existent error in my typing as a result.

Reported by misterx on 16 Dec 2006 22:26 UTC

This happens on ubuntu (and maybe other distro) with [airmon-ng <start|stop> [channel](18]:

usage:)
 
-e Interface    Chipset         Driver
 
-e -n wifi0             Atheros         madwifi-ng
 
[: 377: ==: unexpected operator
-e -n ath0              Atheros         madwifi-ng VAP (parent: wifi0)

Reported by hirte on 23 Dec 2006 21:53 UTC

"pthread_create failed: Cannot allocate memory" when specifying too many capture files.

A possible solution would be to limit the number of concurrent threads and reuse threads to read more than one pcap-file.

Reported by misterx on 7 Jan 2007 22:14 UTC

-y option is not listed on the help screen (shared key authentication).
It also has to be added to the manpage

Reported by misterx on 16 Dec 2006 15:49 UTC

Sometimes it gives an error telling that one changeset doesn't exist.

This will be fixed when debian will release Trac 0.10.3

Reported by anonymous on 3 Jan 2007 23:10 UTC

It would be really interesting to run aircrack on pocket pc devices.

Reported by misterx on 12 Dec 2006 21:29 UTC

See http://tinyshell.be/aircrackng/forum/index.php?topic=653.0 for details

These patches must be applied in the following order:

• aircrack-ng-wepdict
• airodump-ng-filter
• airodump-ng-wepwedgie
• airodump-ng-encryption
• airodump-ng-rxquality
• airodump-ng-ssid_length
• packetforge-ng-ttl