BT4 beta + 3945ABG: deauth does not work (WPA)

[ch4rli3]

Hi all !
I had some troubles with my Intel 3945ABG wifi network controller and BT3 so, as I learn that BT4 is 'ready out of the box' for my wifi, I start to use it (live version).

I'm trying to improve my wlan security (WPA) but, till now,my work is stopped at first step. Problem is: I'm not able to cause a client's de-authentication.

Let me introduce scenario to you.
With kismet I get following infos:

BSSID     : AA.CC.EE.SS.PO.IN
Carrier    : IEEE 802.11b
Carrier    : IEEE 802.11g
Matched : AA:CC:EE:00:00:00/FF:FF:FF:00:00:00
Maxrate  : 11.0
Max seen: 54000kbps
Type      : Access Point
Channell  : 11

Driver used is iwl3945.
Please, someone could confirm that BT4 use a modified version able to inject?

System under test is as follow:
AP [1st floor] <---> sniffer/injecter [1st floor] <---> client [2nd floor]
Now, have a look to the power:
AP is received with -62
client is received with -74

If I've well understood, this configuration is the best for a deauth attack.. isn't it ?

Procedure is as follow:

____TERMINAL 'A'____
airmon-ng start wlan0 11
airodump-ng -c 11 -w secutest --bssid AA.CC.EE.SS.PO.IN wlan0

____TERMINAL 'B'____
aireplay-ng -0 5 -a AA.CC.EE.SS.PO.IN -c WI:FI:CL:IE:NT:xx wlan0

With injection script (aireplay-ng) I get:

Sending 64 directed DeAuth. STMAC:[WI:FI:CL:IE:NT:xx] [114|28 ACKs]
Sending 64 directed DeAuth. STMAC:[WI:FI:CL:IE:NT:xx] [110|29 ACKs]
Sending 64 directed DeAuth. STMAC:[WI:FI:CL:IE:NT:xx] [97|34 ACKs]
Sending 64 directed DeAuth. STMAC:[WI:FI:CL:IE:NT:xx] [109|44 ACKs]
Sending 64 directed DeAuth. STMAC:[WI:FI:CL:IE:NT:xx] [76|34 ACKs]

If I've well understood, ACKs indicate that client receive DeAuth..
The bad is that I have no handshake.
I did a lot of attempts, I try also with aireplay-ng -0 100....

What I'm doing wrong?
I try also changing rate (also 1M) but nothing happens.
What about the carrier (802.11b/g) ?

Thanks in advance for your help!!
ch4rli3

P.S.
Kismet sometimes found some strange mac:
FF:FF:FF:FF:FF:FF
33:33:00:00:00:00
What does it means?

I made some other test. Now, my configuration is:

AP <----> BT4beta <----> Nokia N95
All of them in the same room.

PC with BT4 beta receive AP with -19 and N95 with -45.

I'm able to get a valid handshake ONLY when I connect the phone to the AP.
Once connected, I'm not able to deauthorize (aireplay) the phone.
Procedure is the same as previous post.

Please, let me understand:

1) I receive ACKs from phone and AP.
------------------------------------
Is this sufficient to be sure that DeAuth packet are received ?
If it's sufficient, why deauth does not works?
I made also some try with a vista netbook (friend of mine) with same result: ACKs but no deauth.


2) wlan0 & mon0 mode: monitor.
-------------------------------
Is it the correct configuration or, in order to inject, wlan0 should be in managed and mon0 in monitor mode ?


3) Speed.
----------
I made various attempts with speed. Should I play with speed ? How ?


4) Power.
----------
I try to increase sending power without results.. Some suggestion?

5) Procedure.
-------------
Is the procedure correct?


Missing deauth could be explained with a faulty injection...but... what about ACKs?

Please help.
Thanks,
ch4rli3

Ok, I have success with deauth and I'm happy to share.
Procedure that not work was:
aireplay-ng -0 5 -a AP_MAC -c CLIENT_MAC wlan0
procedure that work is:
aireplay-ng -0 0 -a AP_MAC wlan0

I'd like to know what does ACKs (from client) means and why first procedure does not work.
Mah...

I also found that, in order to save the battery, N95 (and maybe other phones) activate wifi just when it need to transmit and receive. So, when you try to attack, you need to have phone's wifi active (generating traffic)!!

Have a nice aireplay!!

[imported_vvpalin]

Someone correct me if im wrong but the only difference between the 2 commands "besides one focusing on a specific client" is the 0 and 5 option ... and i believe that is packet size or fudge factor

it should work the same if you do

aireplay-ng -0 0 -a AP_MAC -c CLIENT_MAC wlan0

in fact even better because it will directly target the client rather than sending a mass deauth

I forgot to mention "and i cant edit my post im too n00b" you asked what ACK was so here it is.

The ACK signal is sent by the receiving station (destination) back to the sending station (source) after the receipt of a recognizable block of data of specific size. In order to be recognizable, the data block must conform to the protocol in use. When the source receives the ACK signal from the destination, it transmits the next block of data. If the source fails to receive the ACK signal, it either repeats the block of data or else ceases transmission, depending on the protocol.

[ch4rli3]

it should work the same if you do

aireplay-ng -0 0 -a AP_MAC -c CLIENT_MAC wlan0

in fact even better because it will directly target the client rather than sending a mass deauth

I forgot to mention "and i cant edit my post im too n00b" you asked what ACK was so here it is.

The ACK signal is sent by the receiving station (destination) back to the sending station (source) after the receipt of a recognizable block of data of specific size.

aireplay-ng -0 0 -a AP_MAC -c CLIENT_MAC wlan0 does not works...
aireplay-ng -0 0 -a AP_MAC wlan0 works

What it is very strange (form me) are the ACKs received: I have ACKs but no deauth...
Any ideas?

Regards all!