Unfortunately there is no way to determine the MIC length just from the
eapol frame. 802.11 defined AKMs define the MIC length, but non 802.11
AKMs (e.g. OWE) can define their own MIC length. For this reason it seem
infeasable to track these special AKM's data flow to determine the MIC
length.
To work around this we can just try different MIC lengths (since there
are only 3 after all). This allows us to get key data length and see if
the total packet size equals the frame length + key data length. If the
sizes don't match we can try the next MIC length.
The MIC length was hard coded to 16 bytes everywhere, and since several
AKMs require larger MIC's (24/32) this needed to change. The main issue
was that the MIC was hard coded to 16 bytes inside eapol_key. Instead
of doing this, the MIC, key_data_length, and key_data elements were all
bundled into key_data[0]. In order to retrieve the MIC, key_data_len,
or key_data several macros were introduced which account for the MIC
length provided.
A consequence of this is that all the verify functions inside eapol now
require the MIC length as a parameter because without it they cannot
determine the byte offset of key_data or key_data_length.
The MIC length for a given handshake is set inside the SM when starting
EAPoL. This length is determined by the AKM for the handshake.
to fix compilation against MUSL libc.
The struct ethhdr does exists in netinet/if_ether.h and linux/if_ether.h
so including the linux headers after the libc headers lets libc_compat.h
work as intended.
The subtype was only printed if mpdu_validate had returned an error for
the frame, i.e. would not be printed for well formed frames. This was
probably an intent to avoid printing the frame subtype after all the
conents of the body frame had been printed already, but iwmon only
supports printing of Authentication and Deauthentication frames so far.
Kernel v4.10 and later no longer export GENL_ID_GENERATE (which was
defined as 0). iwd was using this symbol to check for unmodified local
values rather than to ask for a dynamically generated netlink ID anyway,
so it makes sense to use the value 0 directly. This will work with
kernels before and after the GENL_ID_GENERATE change.
