Days ago I was dumping handshakes of my APs using airodump-ng. I would later use aircrack-ng to crack them using wordlists which would purposely contain the passphrases. However, I noticed that some handshakes of the same AP cracked while others didn't. I'd recapture the handshake again and again and test, however, not all of them cracked. So I started to inspect them using wireshark and I found no difference between a successfully cracked handshake and a failed one, they both contained:

the beacon

the M1

the M2

I once came across a post explaining that in order for a handshake to be healthy and enough for cracking it should contain:

the M2 (a must)

the M3 or the M1 (the M3 is preferred)

and possibly the beacon

So my question is what's the factor that makes a handshake suitable for cracking? Surely the eapol messages are a must but there must be something else judging. It is really inefficient and blind to capture a handshake, try to crack it, and assume the AP is secure just because the cracking failed, maybe the handshake wasn't healthy in the first place.

  • Try updating the version of aircrack-ng, they just released (10 days ago - April 15, 2018) version 1.2, not anymore an RC. Theoretically you got all what you need so maybe it was a bug? Have you tried using Hashcat, Kismet, or any other tool that's not aircrack-ng?
    – Azteca
    Commented Apr 25, 2018 at 17:54
  • I tried, the problem really doesn't change. Sometimes, the AP is far away and only one crippled handshake is captured. And sometimes this handshake doesn't crack although it should. I need to understand whether the handshake is valid for wasting time cracking and assuming its a secure AP. I tried analyzing as I described above with no help. Commented Apr 29, 2018 at 15:40
  • I can provide you with the two handshakes to examine if this helps. Commented Apr 29, 2018 at 15:42
  • files.fm/u/9afxqhzs#_ Commented Apr 29, 2018 at 16:02

1 Answer 1


You need M2 and (M3 or M1), and they must belong to the same single set of corresponding authentication (i.e., if the first authentication exchange fails, and there is a second, you won't be able to succeed using M2 from the first negotiation and M3 from the second).

The first thing to check is to load the capture log into Wireshark and verify that the value for the field Replay Counter is equal to n (for M1 and M2) and n+1 (for M3 and M4).

Still, as Replay Counter will be frequently reset, you should also check that the interval between M2 and M3 is correct: I've seen about <0.1s working ok, but there is no fixed rule for this value; you should take a look at the rest of the packets and decide if the intervals are plausible, also considering larger values possibly valid because of retransmitted packets.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .