Going through everything to test parsing of the basic ML element and the
RNR element is not really feasible for MBSSID mode. As such, add a unit
test to excercise parsing the available links from the RNR, basic ML
element and MBSSID-Index element if present.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Even though these are not part of run-tests, it is simpler to just build
them like all other tests/test-* tools.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
tests/fuzzing/tls-{client,server} replaced this more than a year ago, so
get rid of the now obsolete version.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
tests/fuzzing/eapol-key-{auth,supp} replaced this more than a year ago,
so get rid of the now obsolete version.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This is something I hadn't previously done, but there are
cases where it's needed, e.g., building 'wlantest' and then
one of the tests/fuzzing/*/ projects, they use a different
configuration (fuzzing vs. not fuzzing).
Perhaps more importantly, this gets rid of the last thing
that was dumped into the source directories, apart from
the binaries themselves.
Note that due to the use of thin archives, this required
building with absolute paths.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of building in the source tree, put most object
files into the build/ folder at the root, and put each
thing that's being built into a separate folder.
This then allows us to build hostapd and wpa_supplicant
(or other combinations) without "make clean" inbetween.
For the tests keep the objects in place for now (and to
do that, add the build rule) so that we don't have to
rewrite all of that with $(call BUILDOBJS,...) which is
just noise there.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Clean up in a more common fashion as well, initially for ../src/.
Also add $(Q) to the clean target in src/
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some things are used by most of the binaries, pull them
into a common rule fragment that we can use properly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Hardcode this to be defined and remove the separate build options for
PMF since this functionality is needed with large number of newer
protocol extensions and is also something that should be enabled in all
WPA2/WPA3 networks.
Signed-off-by: Jouni Malinen <j@w1.fi>
Add test-eapol program that can be used for fuzzing the EAPOL-Key
Supplicant and Authenticator implementations. This tool can write
Supplicant or Authenticator messages into a file as an initialization
step and for the fuzzing step, that file (with potential modifications)
can be used to replace the internally generated message contents.
The TEST_FUZZ=y build parameter is used to make a special build where a
hardcoded random number generator and hardcoded timestamp are used to
force deterministic behavior for the EAPOL-Key operations. This will
also make the implementation ignore Key MIC and AES keywrap errors to
allow processing of modified messages to continue further.
Signed-off-by: Jouni Malinen <j@w1.fi>
Add test-tls program that can be used for fuzzing the internal TLS
client and server implementations. This tool can write client or server
messages into a file as an initialization step and for the fuzzing step,
that file (with potential modifications) can be used to replace the
internally generated message contents.
The TEST_FUZZ=y build parameter is used to make a special build where a
hardcoded random number generator and hardcoded timestamp are used to
force deterministic behavior for the TLS operations.
Signed-off-by: Jouni Malinen <j@w1.fi>
This can be used to build ASCII strings from binary data that is
more likely to use ASCII (i.e., text format is more natural
option than hexdump, but there is possibility of some non-ASCII
characters).
Signed-hostap: Jouni Malinen <j@w1.fi>
src/crypto/libcrypto.a and src/tls/libtls.a have circular references
and will need special handling with the linker at least for the time
being. This could be cleaned up eventually, but for now, provide a
mechanism to get the programs linked.
The new test-asn1 and test-x509 tools are built using libraries
from src/{utils,crypto,tls}. Currently, cross dependencies between
crypto and tls are still preventing the test-x509 from being linked
properly.
