Hi Mem5.
Yes, hcxdumptool sends a few deauthentication messages. That's true.
But hcxdumptool also sends a disassociation after it has received an EAPOL 4/4 (M4) with reason code: WLAN_REASON_DISASSOC_AP_BUSY
In that case, the client must do the authentication again, until hcxdumptool receive an EAPOL 4/4 (M4)...
Also hcxdumptool will send its own EAPOL 1/4 (M1) to a client within a regular authentication. If the clients responds to this one instead of the access points EAPOL 1/4 (M1), he will never get an EAPOL 3/4 (M3).
Right now, hcxdumptool stops this attacks, if it received all necessary data from the client or the access point.
In other words: I we do not stop the attack, the client will never be able to connect to the access point.
I think about an "--infinity" switch (do not stop attack) to disable this behaviour.
Yes, hcxdumptool sends a few deauthentication messages. That's true.
But hcxdumptool also sends a disassociation after it has received an EAPOL 4/4 (M4) with reason code: WLAN_REASON_DISASSOC_AP_BUSY
In that case, the client must do the authentication again, until hcxdumptool receive an EAPOL 4/4 (M4)...
Also hcxdumptool will send its own EAPOL 1/4 (M1) to a client within a regular authentication. If the clients responds to this one instead of the access points EAPOL 1/4 (M1), he will never get an EAPOL 3/4 (M3).
Right now, hcxdumptool stops this attacks, if it received all necessary data from the client or the access point.
In other words: I we do not stop the attack, the client will never be able to connect to the access point.
I think about an "--infinity" switch (do not stop attack) to disable this behaviour.