From this wiki page:

WPA and WPA2 use keys derived from an EAPOL handshake to encrypt traffic. Unless all four handshake packets are present for the session you're trying to decrypt, Wireshark won't be able to decrypt the traffic. You can use the display filter eapol to locate EAPOL packets in your capture.

I've noticed that the decryption works with (1, 2, 4) too, but not with (1, 2, 3). As far as I know the first two packets are enough, at least for what concern unicast traffic. Can someone please explain exactly how does Wireshark deal with that, in other words why does only the former sequence work, given that the fourth packet is just an acknowledgement? Also, is it guaranteed that the (1, 2, 4) will always work when (1, 2, 3, 4) works?

Test case

This is the gzipped handshake (1, 2, 4) and an ecrypted ARP packet (SSID: SSID, password: password) in base64 encoding:


Decode with:

$ base64 -d | gunzip > handshake.cap

Run tshark to see if it correctly decrypt the ARP packet:

$ tshark -r handshake.cap -o wlan.enable_decryption:TRUE -o wlan.wep_key1:wpa-pwd:password:SSID

It should print:

  1   0.000000 D-Link_a7:8e:b4 -> HonHaiPr_22:09:b0 EAPOL Key
  2   0.006997 HonHaiPr_22:09:b0 -> D-Link_a7:8e:b4 EAPOL Key
  3   0.038137 HonHaiPr_22:09:b0 -> D-Link_a7:8e:b4 EAPOL Key
  4   0.376050 ZyxelCom_68:3a:e4 -> HonHaiPr_22:09:b0 ARP is at 00:a0:c5:68:3a:e4
  • It can't.. it must be decrypting because it has all four, or you are connected to the wifi network and that is decrypting the packets
    – Paul
    Apr 17, 2012 at 5:22
  • I'm (obviously) talking about packets captured in RFMON mode.
    – cYrus
    Apr 17, 2012 at 13:17
  • @Paul: I've edited the question; can you reply?
    – cYrus
    Apr 19, 2012 at 9:28
  • I wish I could. If you follow the EAPOL sequence, the client has the PTK after only the first packet (the anonce is passed). The AP knows the PTK after the second packet (snonce). If you observe these two, and know the MACs, which of course you do, and the ssid+psk, then this should be all you need. The third packet is just GTK for broadcast and multicast, and the fourth is just an ACK. If you are decrypting unicast (which the arp-reply is) then the first two packets should be enough. I can't help but think I am missing something as everything says you need all four.
    – Paul
    Apr 19, 2012 at 11:00
  • Did you get any further with this?
    – Paul
    Apr 23, 2012 at 5:18

4 Answers 4


EAPOL exchanges are also used to renew the temporal keys. The new keys are installed on the Supplicant after it sends 4/4, and are installed on the Authenticator when it receives 4/4[1]. If Wireshark must handle rekeying correctly, it must only use the keys after reading the 4/4 packet in the frame, because packets may still be flowing during the rekeying (even in case where they should not, because of buffering)

For the first 4WHS, not waiting for 4/4 is possible, but it's perfectly understandable that they were just lazy to implement it. 3/4 is still necessary as it contains group keys (even if you are not interested in them, but know that you will not see ARP requests from the AP or a client for which you have no part of its 4WHS) and management keys. You may skip 3/4 too, but then you have no confirmation that the exchange was successful, because 3/4 is used to verify that the Authenticator knows the PMK.

[1] Note that with the current scheme, if the 4/4 message is lost, then the supplicant started using the new key, and the authenticator still uses the old key, and resending 3/4 encrypted with the old key will not help. This problem, among many others with WPA2, is addressed in the latest 802.11 2012 standard by keeping two keys in parallel.


All the information necessary to construct the PTK is exchanged in steps 1 and 2. This should be enough to decrypt unicast traffic.

Without step 3, you won't have the GTK, so decrypting multicast/broadcast won't be possible.

Step 4 isn't really necessary to decrypt capture traffic, but if there isn't a step 4, the client/AP won't start using encryption. Wireshark may key off of this before it tries to decrypt data as well.


Well, obviously the WireShark documentation is wrong. :-)

Going off the documentation here:

  • After EAPOL 1 and 2 both sides know the temporal key that will be used to decrypt the traffic.
  • The third message is proof that both sides know the temporal key and indicates that the Authenticator (the base station) is ready to start using the temporal key.
  • The fourth message triggers the switch from the PMK set up before the EAPOL to the temporal key derived in the EAPOL

So with that, it makes sense. WireShark doesn't need message 3 for anything. It knows the keys after messages 1 and 2, but it waits to start using them to decrypt traffic until after it receives message 4.

There are no guarantees to anything in life, especially the behavior of free software, but it's a reasonable bet that there won't be a requirement for message 3 to be present for WireShark to decrypt the session.

  • Seems to me that packet 4 isn't necessary either right - it is just designed to wait for it.
    – Paul
    Apr 29, 2012 at 12:02
  • @Paul, that's sort of like saying "resume" isn't necessary after a "pause".
    – Old Pro
    Apr 29, 2012 at 16:02
  • @OldPro, I'm not sure that waiting for 4° is a good idea, packets captured tend to get lost especially when they travel through the air.
    – cYrus
    Apr 29, 2012 at 18:14
  • @cYrus, waiting for 4 is essential, as encryption keys have to be changed simultaneously on both sides. If the client doesn't receive 4, it doesn't know that the base received 3. If the client doesn't receive 4, it sends 3 again (which triggers a resend of 4) until it either receives 4 or gives up trying to create the connection.
    – Old Pro
    Apr 29, 2012 at 18:20
  • @OldPro: I'm not talking about the protocol. Both sides can receive all the packets, but they might be dropped or not captured by the entity that passively captures the traffic.
    – cYrus
    Apr 29, 2012 at 18:27

This doesn't explain why, but quoting from the airdecap-ng documentation anyways,

WPA/WPA2 Requirements

The capture file must contain a valid four-way handshake. For this purpose having (packets 2 and 3) or (packets 3 and 4) will work correctly. In fact, you don't truly need all four handshake packets. 

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.