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.
