cybergibbons

I don't know if this is a bug with aireplay, madwifi, the hardware, or my head.

My understanding of the ARP reinjection attack is that the packet needs to stay the same, with regards to the encrypted ARP request, and the IV.

I am using aireplay 2.2 and madwifi-cvs-20050814 along with the respective patch.

The card is a D-Link DWL-G650 Hardware Revision C3, ("Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)" from lspci). I've seen reports than the C2 revision works fine with aireplay.

I perform a fake association, which repeats every 30 seconds as this appears to be necessary. This works fine:

aireplay -1 30 -e "My SSID" -a 00:09:4B:XX:XX:XX -h 0:1:2:3:4:5 ath0

I then perform an ARP-reinjection attack:

aireplay -3 -b 00:09:4B:XX:XX:XX -h 0:1:2:3:4:5 ath0

The "Read X packets" count then increases far faster than airodump or kismet report packets coming in. Once 1 ARP packet has been found, the "sent X packets" starts increasing rapidly, as does the "got X ARP requests". The ARP requests quickly hits 1024.

The IVs increase more rapidly in airodump now - but when I look into the file, these new IVs are simply the replayed ARP requests from 0:1:2:3:4:5. Each one of these has a different IV shown in ethereal.

It appears as if aireplay thinks these are new ARP requests, which is why the count increases to 1024 so quickly.

Is the hardware increasing the IVs, or is it a software bug?

Edit

I've now tried with unpatched madwifi-cvs-20050814, and the "Read x packets" increases far more slowly - at about the rate that kismet or airodump report the packets come in.

I also tried the latest madwifi-cvs-20050825 (unpatched, because there is no patch), and the packet count shoots up.

I also tried all of them using "sysctl -w dev.ath0.rawdev=1", and then using the ath0raw interface, but this appears exactly the same.

Edit 2

Appears to be an issue with having to use ath0raw with dev.ath0.rawdev_type=0 (not prism headers). I can now re-inject without IVs changing, and monitor at the same time. Problems with "malformed packets" - I think this is ethereal having issues with the CRC on the end.