most APs are conforming to the standard and send a NACK as expected
when the pin is wrong, but reaver defaulted to assuming the opposite.
this could cause reaver to wrongly assume a correct pin is incorrect
in non-optimal network conditions.
the old default behaviour to treat a timeout as NACK can be accessed
using the new -J / --timeout-is-nack switch.
closes#122
having the switch only dealing with non-UNKNOWN packets makes it possible
to set a breakpoint on it without dealing with non-interesting stuff.
also cleaning up some whitespace mess.
some APs, after having 802.11n HT caps replayed in the association,
embed the EAP frames inside QoS data packets, rather than ordinary
data packets. this fixes an issue introduced with
c7652bae8d .
it slipped my attention during previous refactoring that is_packet_for_us
actually checked 2 things: whether its a valid data packet and whether
its for us. split it into 2 funcs.
some overly pedantic APs require association requests to have
a wireless N "HT capabilities" tag.
json data of one affected model follows:
"wps_manufacturer" : "TP-LINK",
"wps_model_name" : "TL-WR1043ND",
"wps_model_number" : "1.0",
"wps_device_name" : "Wireless Router TL-WR1043ND",
"wps_serial" : "1.0"
as reported in #175.
in preliminary tests no regressions with other routers have been
found, but it may turn out that this change breaks compatibility
to some other models and may need more in-depth study of the subject
and some adjustements.
FCS was disabled in 31cd6da1c4
due to wrong premise that it's not needed, when in fact it was just
too annoying having the terminal spammed with error messages using
a RALINK chipset.
now i turned off the terminal message, but turned the validation back
on. i implemented a new FCS check based on the field in the radiotap
header, as @alex-chan did when he submitted his OS X support patch,
however in a clean fashion, and used for any OS.
the reason this is needed on OSX is that they have very poor drivers
that sometimes submit only half packets, but with the BAD_FCS flag
set, which caused memory corruption and segfaults.
i assume the bad fcs check doesnt kick in now nearly as often as it
did when we disabled the check.
the code was developed for macgeiger[0] and allows comfortable lookup
of all the radiotap fields.
since i plan to use more of them soon, i want a generic solution rather
than reinventing the wheel on every spot.
[0] https://github.com/rofl0r/macgeiger
based on the original patch 7c6c67b445
from alex-chan.
without using this method, mac user get:
error: failed to compile packet filter
since this code works too on other platforms, there's no reason to put
it under ugly #ifdef APPLE's as the original patch did.
lwe/iwlib.c:387:8: warning: explicitly assigning value of variable of type 'char **' to itself [-Wself-assign]
args = args; count = count;
~~~~ ^ ~~~~
lwe/iwlib.c:387:22: warning: explicitly assigning value of variable of type 'int' to itself [-Wself-assign]
args = args; count = count;
~~~~~ ^ ~~~~~
lwe/iwlib.c:1558:9: warning: explicitly assigning value of variable of type 'const char *' to itself [-Wself-assign]
input = input; key = key;
~~~~~ ^ ~~~~~
lwe/iwlib.c:1558:22: warning: explicitly assigning value of variable of type 'unsigned char *' to itself [-Wself-assign]
input = input; key = key;
~~~ ^ ~~~
Multiple memcmps of nonces were actually comparing only the first byte
instead of all 16 bytes. [Bug 462]
Signed-hostap: Eyal Shapira <eyal@wizery.com>
intended-for: hostap-1
(cherry picked from commit b4e9e2659b97865f7950ae467a3d828b768c78de)
Note from @rofl0r
cherry-picked this patch from [0] even though it probably doesn't affect
codepaths used by reaver in order to mute warnings from clang.
[0] https://w1.fi/cgit/hostap-1/commit/src/wps/wps_registrar.c?id=9ce7f1974e1a685b1c0b1112e322bbe20ed0212b
some APs send several authentication success messages in a burst,
and our associate_recv_loop, when waiting for an association response,
would return when getting such a packet, and immediately try to send
another assoc request until MAX_TRIES was hit, and then restarting
the whole dance again with a deauth packet.
this time, we encountered cases where due to the brainbending logic
in this code reaver thought we were associated when we weren't -
in fact, we didnt even get an auth reply.
rofl0r
alex-chan
Eyal Shapira
kcdtv