Check the IE order for each frame type where we'd just do the body
minimum length check until now (and not always correctly). We do not
try to validate the contents of any IEs (may be doable for some) or the
minimum mandatory IEs presence. This is because which IEs are required
depend on the contents of other fields in the frame, on the
authentication state and STA config and even contents of a request frame
which we're validating the response to. Frame handlers have to do this
work anyway.
Declare the two missing frame subtype enum values for Action frames,
assume Action frames are valid. Once we have specific validation code
for any Action frames elsewhere, we can move it to mpdu_validate, but
right don't try to validate the frame body as there are many subtypes
and we don't use any of them except Neighbor Reports which are actually
really simple.
Since we use the special 0xffff value in the builder code, check that
the tag is not 0xffff in ie_tlv_builder_finalize before writing the
header. This is for consistency, not for a specific use case.
Make parsing TLVs using Extended Element IDs easier by returning the
extended tag value as listed in enum ie_type instead of just the 255
value, and not returning the pointer to the extended tag as the IE data
and instead the pointer to the next byte after the extended ID.
Replace is_multicast_addr with util_is_broadcast_address usage.
is_multicast_addr seems to have been wrong, first because we're not
interested in just any multicast address (defined to be same as "group
address"), but rather specifically the broadcast address, as we don't
know of any specific address groups other than broadcast. And also
wrong because the "Individual/Group bit" is the LSB of byte 0, not the
MSB of byte 0 apparently.
The l_queue_find() to find other watches matching the new prefix
needs to be before the watchlist_link(), otherwise the prefix will
match itself and "registered" is always true.
In WATCHLIST_NOTIFY_MATCHES pass pointer to the item instead of
item->notify_data to free item->notify_data to be the final watch user's
user_data. This is also what netdev expects.
The EAP-method's .probe methods only checked the method name so do that
in eap.c instead and allocate method state in .load_settings. Rename
method's .remove method to .free to improve the naming.
This can be used to selectively notify watchlist items. The match
function is called for each watchlist_item and match_data is passed
along. If the match function returns true, then the watch_item is
notified. The match function signature and semantics are identical
to l_queue_match_func_t.
Rename netdev_register_frame to netdev_frame_watch_add and expose to be
usable outside of netdev.c, add netdev_frame_watch_remove also. Update
the Neighbor Report handling which was the only user of
netdev_register_frame.
The handler is now simpler because we use a lookup list with all the
prefixes and individual frame handlers only see the frames matching the
right prefix. This is also useful for the future Access-Point mode.
src/mpdu.c: In function ‘mpdu_validate’:
src/mpdu.c:180:9: error: ‘mmpdu’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
mmpdu = (const struct mmpdu_header *) mmpdu;
^
Refactor management frame structures to take into account optional
presence of some parts of the header:
* drop the single structure for management header and body since
the body offset is variable.
* add mmpdu_get_body to locate the start of frame body.
* drop the union of different management frame type bodies.
* prefix names specific to management frames with "mmpdu" instead
of "mpdu" including any enums based on 802.11-2012 section 8.4.
* move the FC field to the mmpdu_header structure.
Since aes_wrap & aes_unwrap advertise support for overlapped in/out
buffers, make sure that the unit test actually tests this as well.
valgrind will complain if the memory is overlapped and memcpy is used
instead of memmove.
This EAP method uses nearly all the logic from EAP-AKA. The major
difference is it uses the new key derivation functions for AKA' as
well as the SHA256 MAC calculation.
EAP-AKA' uses SHA256 rather than SHA1 to generate the packet MAC's.
This updates the derive MAC API to take the EAP method type and
correctly use the right SHA variant to derive the MAC.
This is the core key generation code for the AKA' method which
follows RFC 5448. Two new functions are implemented, one for
deriving CK'/IK' and the other for deriving the encryption keys
using CK'/IK'.
