[gBarreras]

I cannot find a way to get a Handshake from my own wireless network, which has a WPA2 encryption. Please, note that this is not the first time I do this at all. In fact, I've captured tons of Handshakes, even when I did not have any idea of what I was doing. My goal is to isolate every possible reason of the capturing failure.

I'm running Kali Linux OS, installed on my hard disk. My network card is an alfa awus036h, whose chipset is rtl8187. I execute the following commands:

Code:

airmon-ng start wlan1
ifconfig wlan1 down
airodump-ng -c 3 --bssid <my_router_mac> -w cap mon0

Obviously, my alfa card does support injection. Anyway, I check it by executing

Code:

aireplay-ng -9 mon0

Once I've started sniffing, I try to disconnect manually from the network either my laptop connection with wlan0 interface (which is an Atheros integrated card), my Android phone or a Windows computer.

However, airodump does not show the Handshake found notification at all, even I've been sniffing during more than an hour.

Additional precautions:

• I've did those disconnection/connection test while I'm sniffing from several rooms. One of them gets a power range of [-25, -40], and the other room gets [-40,-55] approximately.
  
  
• I've read is possible that airodump got a full Handshake but it doesn't show the notification. So, to be sure, it's recommended to check it by executing
  Code:

  cowpatty -c -r <cap_file>
  . Its output says there is not a complete four-way handshake, so I believe I'm actually not getting the handshake.
  
• Also tried to send deauthentication packets to the Android client with
  Code:

  aireplay-ng -0 10 -a <my_router_mac> -c <android_phone_mac>
mon0
  , which I did achieve to disconnect when the android phone was close enough to my pentesting laptop. I don' think the way of connecting/disconnecting (manually or by deauth packets) matters in this case.
  

Do you know any reason why it is not working?

Thank you!

[L0aD1nG]

I think this will work for you try it out and tell me. Adjust your interface names to fit your needs.

Open a terminal and type this down:

Code:

airmon-ng start wlan0
airodump-ng -c <your channel> --bssid <your router's bssid> -w <custom name of the file to capture info> mon0

Open another terminal and type the following:

Code:

aireplay-ng -0 1 -a <router's bssid> -c <mac address of another devide not the same> mon0

Then go check the first terminal in the up-right corner it prints now WPA Handshake . If it doesn't let some seconds pass and the rerun the second's terminal command over and over again but don't spam it like -0 10 or -0 100 this is not the proper way to do it except if you have been making tries like I told you many times and you can't achieve it.

At last open another terminal and run:

Code:

aircrack-ng -w <custom dictionary> <custom name of the file that captured all the info>.cap

If the dictionary contains your password it should find it.

From my perspective you made 2 mistakes:

1. You brought the wireless interface down with ifconfig wlan1 down and never brought it up again.
   
2. You tried to run the aireplay-ng method on the same devide that you were capturing with, (the attacker machine was the same with the victim one)
   

I hope this helped you out.
Cheers!

[gBarreras]

Hi,
thank you L0aD1nG for response.
However, I could not achieve it.
I tried to send a single packet, as you suggested. Even so, Handshake did not appear.

Also, you said that one problem could be the victim machine and the attacker one, were the same machine. That's not true. As I said:

Once I've started sniffing, I try to disconnect manually from the network either my laptop connection with wlan0 interface (which is an Atheros integrated card), my Android phone or a Windows computer.

I often use my Android phone as the victim machine, enabling and disabling the wireless connection. That should be enough, and deauthentication would not even be necessary. Anyway, nor deauthentication nor manual desconnection from the victim machine, make the WPA Handshake appear.

Related with your first mistake suggestion:

You brought the wireless interface down with ifconfig wlan1 down and never brought it up again.

The reason why I brought wlan1 interface down was to solve the problem of "fixed channel -1 on mon0". If I don't bring wlan1 down, some processes as dhclient, supplicant and so, cause problems on mon0 while sniffing. That makes that, a message saying "fixed channel -1 on mon0" appears on the place where the "WPA Handshake found" message should be shown.

I don't get it. I can capture handshakes from some networks, but there are other networks, as my own network, where I cannot achieve it.

Some additional suggestion?
Thank you!

[L0aD1nG]

Okay I might miss-understood, but I when I read it I thought it was about the same machine... :Grin:

Well the first thing I should tell you is that on some of the last Beta updates of aircrack the fixed channel -1 on mon0 can be fixed pass a specific parameter like :

Code:

airodump-ng --ignore-negative-one -c <channel> --bssid <router's bssid> -w <file> mon0

So you don't really need to force the interface down. Thought remember you must pass on aireplay-ng too. I guess you use the wlan0 interface for the job...

You can try spam deauth packages... like 0-100 or even 0-1000, sometime distance plays important role about the deauth package in real time tries. Some routers at least here in my country aren't able to be handshaked with either spamming or single deauth of the Internet User but there kind is still rare. Either your router is one of those or you do something wrong, I don't know a more efficient way of doing this job it worked for me like more than 90% of the times I 've used it.

EDIT : Try use the '@' symbol before my name when you are mention me so I will be able to know that you mentioned me by an alert and read the post as fast as possible dude. Cheers!

[L0aD1nG]

Okay I might miss-understood, but I when I read it I thought it was about the same machine... :Grin:

Well the first thing I should tell you is that on some of the last Beta updates of aircrack the fixed channel -1 on mon0 can be fixed pass a specific parameter like :

Code:

airodump-ng --ignore-negative-one -c <channel> --bssid <router's bssid> -w <file> mon0

So you don't really need to force the interface down. Thought remember you must pass on aireplay-ng too. I guess you use the wlan0 interface for the job...

You can try spam deauth packages... like 0-100 or even 0-1000, sometime distance plays important role about the deauth package in real time tries. Some routers at least here in my country aren't able to be handshaked with either spamming or single deauth of the Internet User but there kind is still rare. Either your router is one of those or you do something wrong, I don't know a more efficient way of doing this job it worked for me like more than 90% of the times I 've used it.

EDIT : Try use the '@' symbol before my name when you are mention me so I will be able to know that you mentioned me by an alert and read the post as fast as possible dude. Cheers!

[L0aD1nG]

Okay I might miss-understood, but I when I read it I thought it was about the same machine... :Grin:

Well the first thing I should tell you is that on some of the last Beta updates of aircrack the fixed channel -1 on mon0 can be fixed pass a specific parameter like :

Code:

airodump-ng --ignore-negative-one -c <channel> --bssid <router's bssid> -w <file> mon0

So you don't really need to force the interface down. Thought remember you must pass on aireplay-ng too. I guess you use the wlan0 interface for the job...

You can try spam deauth packages... like 0-100 or even 0-1000, sometime distance plays important role about the deauth package in real time tries. Some routers at least here in my country aren't able to be handshaked with either spamming or single deauth of the Internet User but there kind is still rare. Either your router is one of those or you do something wrong, I don't know a more efficient way of doing this job it worked for me like more than 90% of the times I 've used it.

EDIT : Try use the '@' symbol before my name when you are mention me so I will be able to know that you mentioned me by an alert and read the post as fast as possible dude. Cheers!

[gBarreras]

Once again, thank you @L0aD1nG for your response.
However:

Well the first thing I should tell you is that on some of the last Beta updates of aircrack the fixed channel -1 on mon0 can be fixed pass a specific parameter like :

Code:

airodump-ng --ignore-negative-one -c <channel> --bssid <router's bssid> -w <file> mon0

So you don't really need to force the interface down. Thought remember you must pass on aireplay-ng too. I guess you use the wlan0 interface for the job...

I had read latests versions of aircrack presented that "fixed channel -1" bug, which I don't think is a bug, at all.

When I bring up my wlan1 interface using airmon-ng this is what console prints:

Code:

root@kali:/home/gabriel# airmon-ng start wlan1


Found 4 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!
-e
PID    Name
2566    NetworkManager
2672    wpa_supplicant
2810    dhclient
3319    dhclient
Process with PID 2810 (dhclient) is running on interface wlan0


Interface    Chipset        Driver

wlan1        Realtek RTL8187L    rtl8187 - [phy1]
                (monitor mode enabled on mon0)
wlan0        Atheros AR9285    ath9k - [phy0]

I'm not sure, but what I think is that aircrack-ng warns me about that "fixed channel -1" because processes 2566, 2672 and 3319 (all of them except 2810, which is said to be used by wlan0 interface) are trying to set the channel of the interface to a channel which is not the same as airodump-ng and aireplay-ng are using.

Despite of showing that trouble warning, mon0 is brought up anyway. However, if you try to sniff with airodump-ng or inject with aireplay-ng, you get the error message informing that your mon0 interface is fixed at channel -1. By this, what I understand is mon0 interface cannot focus on the correct frequency (or channel), because of those processes previously shown, since we know that one radio/wireless interface can only work on a single channel or frequency simultaneously.
So, my point is, setting "--ignore-negative-one" flag is not actually solving the problem. It is true that airodump-ng is executed and it doesn't show "fixed channel -1" error; and aireplayng is executed too, but it warns you about your interface being on -1 channel instead of the channel of the AP. I don't think any aireplay-ng injection can be successful this way.

Another way I know to solve the "fixed channel -1" problem, instead of to bring wlan1 interface down, is to execute

Code:

airmon-ng check kill mon0"

It will check all those processes that could cause problems on mon0, and then it will kill them all.

That said, I want you to consider again if the problem is my monitor interface or not.

In the other hand, I don't think the problem is that the AP is not deauthenticating a legitimate user. In fact, I actually see how my Android phone gets disconnected from the network when it receives some deauth. packets. The problem is when I stop sending them, it gets connected again but I get no handshake.

I don't know if I'm right. Maybe I'm leaving out some important thing. If not, have I convinced you?

Could it be a problem related with signal power? I've read somewhere that, staying too close to the AP makes handshake extraction harder...but I've also tried to capture it from the farthest room, which gets a power of -50, -55 aprox.

Finally, my AP it's a Livebox 2.1. I couldn't find so much information about it in english: http://en.wikipedia.org/wiki/Orange_Livebox#Livebox_2

Thank you for your help.
Cheers!

[gBarreras]

Once again, thank you @L0aD1nG for your response.
However:

Well the first thing I should tell you is that on some of the last Beta updates of aircrack the fixed channel -1 on mon0 can be fixed pass a specific parameter like :

Code:

airodump-ng --ignore-negative-one -c <channel> --bssid <router's bssid> -w <file> mon0

So you don't really need to force the interface down. Thought remember you must pass on aireplay-ng too. I guess you use the wlan0 interface for the job...

I had read latests versions of aircrack presented that "fixed channel -1" bug, which I don't think is a bug, at all.

When I bring up my wlan1 interface using airmon-ng this is what console prints:

Code:

root@kali:/home/gabriel# airmon-ng start wlan1


Found 4 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!
-e
PID    Name
2566    NetworkManager
2672    wpa_supplicant
2810    dhclient
3319    dhclient
Process with PID 2810 (dhclient) is running on interface wlan0


Interface    Chipset        Driver

wlan1        Realtek RTL8187L    rtl8187 - [phy1]
                (monitor mode enabled on mon0)
wlan0        Atheros AR9285    ath9k - [phy0]

I'm not sure, but what I think is that aircrack-ng warns me about that "fixed channel -1" because processes 2566, 2672 and 3319 (all of them except 2810, which is said to be used by wlan0 interface) are trying to set the channel of the interface to a channel which is not the same as airodump-ng and aireplay-ng are using.

Despite of showing that trouble warning, mon0 is brought up anyway. However, if you try to sniff with airodump-ng or inject with aireplay-ng, you get the error message informing that your mon0 interface is fixed at channel -1. By this, what I understand is mon0 interface cannot focus on the correct frequency (or channel), because of those processes previously shown, since we know that one radio/wireless interface can only work on a single channel or frequency simultaneously.
So, my point is, setting "--ignore-negative-one" flag is not actually solving the problem. It is true that airodump-ng is executed and it doesn't show "fixed channel -1" error; and aireplayng is executed too, but it warns you about your interface being on -1 channel instead of the channel of the AP. I don't think any aireplay-ng injection can be successful this way.

Another way I know to solve the "fixed channel -1" problem, instead of to bring wlan1 interface down, is to execute

Code:

airmon-ng check kill mon0"

It will check all those processes that could cause problems on mon0, and then it will kill them all.

That said, I want you to consider again if the problem is my monitor interface or not.

In the other hand, I don't think the problem is that the AP is not deauthenticating a legitimate user. In fact, I actually see how my Android phone gets disconnected from the network when it receives some deauth. packets. The problem is when I stop sending them, it gets connected again but I get no handshake.

I don't know if I'm right. Maybe I'm leaving out some important thing. If not, have I convinced you?

Could it be a problem related with signal power? I've read somewhere that, staying too close to the AP makes handshake extraction harder...but I've also tried to capture it from the farthest room, which gets a power of -50, -55 aprox.

Finally, my AP it's a Livebox 2.1. I couldn't find so much information about it in english: http://en.wikipedia.org/wiki/Orange_Livebox#Livebox_2

Thank you for your help.
Cheers!

[L0aD1nG]

Once again, thank you @L0aD1nG for your response.
However:

Well the first thing I should tell you is that on some of the last Beta updates of aircrack the fixed channel -1 on mon0 can be fixed pass a specific parameter like :

Code:

airodump-ng --ignore-negative-one -c <channel> --bssid <router's bssid> -w <file> mon0

So you don't really need to force the interface down. Thought remember you must pass on aireplay-ng too. I guess you use the wlan0 interface for the job...

I had read latests versions of aircrack presented that "fixed channel -1" bug, which I don't think is a bug, at all.

When I bring up my wlan1 interface using airmon-ng this is what console prints:

Code:

root@kali:/home/gabriel# airmon-ng start wlan1


Found 4 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!
-e
PID    Name
2566    NetworkManager
2672    wpa_supplicant
2810    dhclient
3319    dhclient
Process with PID 2810 (dhclient) is running on interface wlan0


Interface    Chipset        Driver

wlan1        Realtek RTL8187L    rtl8187 - [phy1]
                (monitor mode enabled on mon0)
wlan0        Atheros AR9285    ath9k - [phy0]

I'm not sure, but what I think is that aircrack-ng warns me about that "fixed channel -1" because processes 2566, 2672 and 3319 (all of them except 2810, which is said to be used by wlan0 interface) are trying to set the channel of the interface to a channel which is not the same as airodump-ng and aireplay-ng are using.

Despite of showing that trouble warning, mon0 is brought up anyway. However, if you try to sniff with airodump-ng or inject with aireplay-ng, you get the error message informing that your mon0 interface is fixed at channel -1. By this, what I understand is mon0 interface cannot focus on the correct frequency (or channel), because of those processes previously shown, since we know that one radio/wireless interface can only work on a single channel or frequency simultaneously.
So, my point is, setting "--ignore-negative-one" flag is not actually solving the problem. It is true that airodump-ng is executed and it doesn't show "fixed channel -1" error; and aireplayng is executed too, but it warns you about your interface being on -1 channel instead of the channel of the AP. I don't think any aireplay-ng injection can be successful this way.

Another way I know to solve the "fixed channel -1" problem, instead of to bring wlan1 interface down, is to execute

Code:

airmon-ng check kill mon0"

It will check all those processes that could cause problems on mon0, and then it will kill them all.

That said, I want you to consider again if the problem is my monitor interface or not.

In the other hand, I don't think the problem is that the AP is not deauthenticating a legitimate user. In fact, I actually see how my Android phone gets disconnected from the network when it receives some deauth. packets. The problem is when I stop sending them, it gets connected again but I get no handshake.

I don't know if I'm right. Maybe I'm leaving out some important thing. If not, have I convinced you?

Could it be a problem related with signal power? I've read somewhere that, staying too close to the AP makes handshake extraction harder...but I've also tried to capture it from the farthest room, which gets a power of -50, -55 aprox.

Finally, my AP it's a Livebox 2.1. I couldn't find so much information about it in english: http://en.wikipedia.org/wiki/Orange_Livebox#Livebox_2

Thank you for your help.
Cheers!

First of all, "fixed channel -1" its a bug of aircrack new versions. I can ensure you for that. Now I know that when you cast the deauth packages it stills says that you are on channel -1 but its not true cause as we both know you set it to --ignore-negative-one, so this is fixing the problem for you. Otherwise if the problem wasn't fixed by this tactic you would get the same message and the packages wouldn't arrive to deauth the user... The fact that the user is deauthed means that you are sending them to the correct channel (thats the proof).

Now as for the range you told me in some cases thats the reason that you can't get a handshake but in your case... I don't really think that this is the problem cause this is caused when you are too far away and not when you are too close to the router. I can't really understand what may causing you the failure mate. I will think about it and respond again if I have some new idea.

At last remember that some routers are invalid on the handshake method, so take in consider that maybe your router is one of those.

[L0aD1nG]

Once again, thank you @L0aD1nG for your response.
However:

Well the first thing I should tell you is that on some of the last Beta updates of aircrack the fixed channel -1 on mon0 can be fixed pass a specific parameter like :

Code:

airodump-ng --ignore-negative-one -c <channel> --bssid <router's bssid> -w <file> mon0

So you don't really need to force the interface down. Thought remember you must pass on aireplay-ng too. I guess you use the wlan0 interface for the job...

I had read latests versions of aircrack presented that "fixed channel -1" bug, which I don't think is a bug, at all.

When I bring up my wlan1 interface using airmon-ng this is what console prints:

Code:

root@kali:/home/gabriel# airmon-ng start wlan1


Found 4 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!
-e
PID    Name
2566    NetworkManager
2672    wpa_supplicant
2810    dhclient
3319    dhclient
Process with PID 2810 (dhclient) is running on interface wlan0


Interface    Chipset        Driver

wlan1        Realtek RTL8187L    rtl8187 - [phy1]
                (monitor mode enabled on mon0)
wlan0        Atheros AR9285    ath9k - [phy0]

I'm not sure, but what I think is that aircrack-ng warns me about that "fixed channel -1" because processes 2566, 2672 and 3319 (all of them except 2810, which is said to be used by wlan0 interface) are trying to set the channel of the interface to a channel which is not the same as airodump-ng and aireplay-ng are using.

Despite of showing that trouble warning, mon0 is brought up anyway. However, if you try to sniff with airodump-ng or inject with aireplay-ng, you get the error message informing that your mon0 interface is fixed at channel -1. By this, what I understand is mon0 interface cannot focus on the correct frequency (or channel), because of those processes previously shown, since we know that one radio/wireless interface can only work on a single channel or frequency simultaneously.
So, my point is, setting "--ignore-negative-one" flag is not actually solving the problem. It is true that airodump-ng is executed and it doesn't show "fixed channel -1" error; and aireplayng is executed too, but it warns you about your interface being on -1 channel instead of the channel of the AP. I don't think any aireplay-ng injection can be successful this way.

Another way I know to solve the "fixed channel -1" problem, instead of to bring wlan1 interface down, is to execute

Code:

airmon-ng check kill mon0"

It will check all those processes that could cause problems on mon0, and then it will kill them all.

That said, I want you to consider again if the problem is my monitor interface or not.

In the other hand, I don't think the problem is that the AP is not deauthenticating a legitimate user. In fact, I actually see how my Android phone gets disconnected from the network when it receives some deauth. packets. The problem is when I stop sending them, it gets connected again but I get no handshake.

I don't know if I'm right. Maybe I'm leaving out some important thing. If not, have I convinced you?

Could it be a problem related with signal power? I've read somewhere that, staying too close to the AP makes handshake extraction harder...but I've also tried to capture it from the farthest room, which gets a power of -50, -55 aprox.

Finally, my AP it's a Livebox 2.1. I couldn't find so much information about it in english: http://en.wikipedia.org/wiki/Orange_Livebox#Livebox_2

Thank you for your help.
Cheers!

First of all, "fixed channel -1" its a bug of aircrack new versions. I can ensure you for that. Now I know that when you cast the deauth packages it stills says that you are on channel -1 but its not true cause as we both know you set it to --ignore-negative-one, so this is fixing the problem for you. Otherwise if the problem wasn't fixed by this tactic you would get the same message and the packages wouldn't arrive to deauth the user... The fact that the user is deauthed means that you are sending them to the correct channel (thats the proof).

Now as for the range you told me in some cases thats the reason that you can't get a handshake but in your case... I don't really think that this is the problem cause this is caused when you are too far away and not when you are too close to the router. I can't really understand what may causing you the failure mate. I will think about it and respond again if I have some new idea.

At last remember that some routers are invalid on the handshake method, so take in consider that maybe your router is one of those.