Is it possible to block EAPOL packets?
What I'm trying to do is block the 4th message of the 4-Way-Handshake in order to trigger retransmission of message 3.

This is what I thought to do. I'd like to know if it's possible or not:

  1. ARP-spoofing to set up a Man-in-the-Middle
  2. Sniff the traffic
  3. Deauthenticate the client to start a new handshake
  4. Block the 4th packet of the 4-way handshake, so that the Access Point will not get it and will send the 3rd message again.
  5. Forward all other packets

Is this actually possible or there is a better and more efficient way to do it?

closed as off-topic by Steffen Ullrich, David, Tobi Nary, iwaseatenbyagrue, Polynomial Jan 25 '18 at 13:25

  • This question does not appear to be about Information security within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • look up scapy – schroeder Jan 17 '18 at 13:41
  • Not entirely sure what you are trying to do, but it doesn't seem like you understand the networking concepts behind this. ARP, IP, and EAPOL do not interact in this way. – multithr3at3d Jan 17 '18 at 17:11
  • @multithr3at3d what I'm trying to do is recreate the Key reinstallation Attacks using already popular tools/attacks, in order to make this attack work the Man in the Middle must block the 4th message from the client to the access point in order to trigger retransmission of message 3. That's why I'm asking how can i block a specific packet with a Man in the Middle – user7337963 Jan 18 '18 at 9:10

You can't do that as stated. ARP spoofing causes a MitM at the IP layer. The 4-way handshake happens in a lower layer, and well before the device obtains an IP address.

You can't prevent the access point from receiving the 4th EAPOL frame without RF jamming. However, there may be ways to desynchronize the state of the handshake such that your desired result is achieved. As schroeder mentioned, Scapy would be ideal for this. For example, sending a deauthentication frame to the AP immediately after message 3 will break the process, causing the client to think it is authenticated when it is not. This causes the client to repeat the handshake once it eventually realizes the state.

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