This test was failing due to a change introduced in commit
5c9de0cf23 which changed handshake state storage of IPs from host
order to network byte order. Update the test to set IPs in network
byte-order.
Fixes: 5c9de0cf23 ("eapol: Store IP address in network byte order")
Incorporate the LGPL v2.1 licensed implementation of ARC4, taken from
the Nettle project (https://git.lysator.liu.se/nettle/nettle.git,
commit 3e7a480a1e351884), and tweak it a bit so we don't have to
operate on a skip buffer to fast forward the stream cipher, but can
simply invoke it with NULL dst or src arguments to achieve the same.
This removes the dependency [via libell] on the OS's implementation of
ecb(arc4), which may be going away, and which is not usually accelerated
in the first place.
test-eapol was passing zero as the MTU, so this simply needed to be
updated to remove that parameter.
test-wsc was actually setting a MTU value so when building the
settings we now add the proper value so the MTU can be set with
__eap_set_config.
Refactored eapol_sm_test_tls to take a l_settings object rather than
a settings string. This lets the caller either load from data or
from file (the new test loads the build time generated tls-settings
file).
FILS authentication does away with the MIC, so checking for key_mic
in the eapol key frame does not allow FILS to work. Now we pass in
the mic_len to eapol_verify_gtk_1_of_2, and if it is non-zero we can
check that the MIC is present in the frame.
Single AVP should not be padded with zeros as padding is only
used to separate AVPs in a sequence.
RFC 5281 Section 10.2. AVP Sequences
Data encapsulated within the TLS record layer must consist entirely
of a sequence of zero or more AVPs. Each AVP must begin on a four-
octet boundary relative to the first AVP in the sequence. If an AVP
is not a multiple of four octets, it must be padded with zeros to the
next four-octet boundary.
Note that the AVP Length does not include the padding.
