Ladies and gentlemen (mostly gentlemen probably),
I noticed that the sent M messages are currently not re-sent if the AP did not
receive them. This is a "practical" feature request, since this does mostly not
occur in laboratory conditions, but on low signal strength setups (aka. the
real world).
Example:
Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message
[+] Received M3 message
[+] Sending M4 message
[+] Received M3 message
[+] Received M3 message
[+] Received M3 message
... timeout ... meh
What I would suggest is a RESEND as soon as a M message is received which has
been received before (eg. re-send M-4 if another M-3 is received).
Currently this is effectively prevented in exchange.c ll 103ff:
case M3:
cprintf(VERBOSE, "[+] Received M3 message\n");
if(m2_sent && !m4_sent)
...
I have no deeper knowledge of the WPS protocoll, so I don't know if this is
impossible to work around, so I went just at it:
I hacked around in the code so that this works and it increased the success
rate massively (from ~200s/key to 20s/key) since not the whole starting
procedure hast to be repeated and wps cooldown is not activated as much (since
it seems to be connected to the eapol start for most AP impl.).
Unfortunately the code is written in a way that this is not intended (since
password and messages are freed from mem as soon as the message is sent). I
just ignored the freeing for now and created a massive memory leak ... Don't
care got enogh ram...
However: This has to be refactored in a way, that the free will only happen if
the next stage in the wps process has been reached - message M-(n+1) is
received - or timeout was reached.
Original issue reported on code.google.com by dbu...@mail.ru on 14 Aug 2015 at 2:13
Original issue reported on code.google.com by
dbu...@mail.ruon 14 Aug 2015 at 2:13