Well, you're right too. In this case, wlandump-ng and hcxdumptool will work like an intelligent WiFi jammer!
Normally APs and clients use a retry counter (we do the same). Default value is 6 retries, then the AP or the client should stop. Some of them have a very high retry counter value - so your log is flooded. I saw some of them which have an unlimited(!) value.
One single packet from us is enough to to start this process. Right now, an attack stops if we received the matching M2 to our M1. That is more than enough for us, because we get a valid and crackable combination M1M2.
By the way: This is one of the reasons why I didn't recommend a high power WiFi dongle like the ALFAs. It is much, much better to use a common low power device and(!) a high gain external antenna like a panel (>12 dBi) or an omni (> 7dBi). This make shure, that you receive all packets within your transmit range.
Please tell me more about the contence of your flooded log:
Is it flooded with our M1 or the M2 from the client? In both cases we do not DOS.
If the log is flooded with M3 or M4 we're working like an intelligent jammer! In that case the AP is under heavy DOS from his own clients.
Take also a look at the cap file:
If the clients (or the APs) retry bit (in frame control field of mac frame) is set, we can't prevent that behavior - it's an issue of the client (or the AP), even if we stop the attack!
In that case the attacker status display will inform you about this behavior: (retransmitted)
The tools are designed to be used if you are highly mobile (that's a reason why I like your Android solution) to capture as much M2 as possible. All important packets (we need them to do forensics and client tracking - I do not mean BEACONs, as the information contained therein is much too general) are saved to the capture file. If you take a look into the source from hcxpcaptool you'll see that the analyzed data went in there (new frame header). Same with the PSKs (cracked.txt from wpa-sec). We we strictly follow the "intelligence cycle". Well, your post (feedpack/feature request) is also a part of this cycle. I'll try to find a solution - but it's still an issue of the client / AP (retry counter value).
For example:
Use a mobile device (raspberry) and sit down on a main street near of a traffic light.
In the phase of red light you will receive many M2s from the clients in the stopped cars (incl. AndroidCar WiFi systems).
Same on a bus stop or a railway station.
A crowded downtown or a department store will bring you also many M2s.
Collect this M2s and(!) the output of the -e -u (wlancap2hcx) or -E -I -U options (hcxpcaptool).
We found many PSKs using a rule on this collected data.
It's also important to analyze the contence of the cap file to find more interesting packets (or packets out of protocol).
If you use hcxtools stationary, you must configure the BPF (-F wlandump-ng) or the blacklist (-B hcxpcaptool)
Normally APs and clients use a retry counter (we do the same). Default value is 6 retries, then the AP or the client should stop. Some of them have a very high retry counter value - so your log is flooded. I saw some of them which have an unlimited(!) value.
One single packet from us is enough to to start this process. Right now, an attack stops if we received the matching M2 to our M1. That is more than enough for us, because we get a valid and crackable combination M1M2.
By the way: This is one of the reasons why I didn't recommend a high power WiFi dongle like the ALFAs. It is much, much better to use a common low power device and(!) a high gain external antenna like a panel (>12 dBi) or an omni (> 7dBi). This make shure, that you receive all packets within your transmit range.
Please tell me more about the contence of your flooded log:
Is it flooded with our M1 or the M2 from the client? In both cases we do not DOS.
If the log is flooded with M3 or M4 we're working like an intelligent jammer! In that case the AP is under heavy DOS from his own clients.
Take also a look at the cap file:
If the clients (or the APs) retry bit (in frame control field of mac frame) is set, we can't prevent that behavior - it's an issue of the client (or the AP), even if we stop the attack!
In that case the attacker status display will inform you about this behavior: (retransmitted)
The tools are designed to be used if you are highly mobile (that's a reason why I like your Android solution) to capture as much M2 as possible. All important packets (we need them to do forensics and client tracking - I do not mean BEACONs, as the information contained therein is much too general) are saved to the capture file. If you take a look into the source from hcxpcaptool you'll see that the analyzed data went in there (new frame header). Same with the PSKs (cracked.txt from wpa-sec). We we strictly follow the "intelligence cycle". Well, your post (feedpack/feature request) is also a part of this cycle. I'll try to find a solution - but it's still an issue of the client / AP (retry counter value).
For example:
Use a mobile device (raspberry) and sit down on a main street near of a traffic light.
In the phase of red light you will receive many M2s from the clients in the stopped cars (incl. AndroidCar WiFi systems).
Same on a bus stop or a railway station.
A crowded downtown or a department store will bring you also many M2s.
Collect this M2s and(!) the output of the -e -u (wlancap2hcx) or -E -I -U options (hcxpcaptool).
We found many PSKs using a rule on this collected data.
It's also important to analyze the contence of the cap file to find more interesting packets (or packets out of protocol).
If you use hcxtools stationary, you must configure the BPF (-F wlandump-ng) or the blacklist (-B hcxpcaptool)