This is currently happening way too frequently (mac80211 monitor
interface sends TX info for every frame) and the end result makes it
difficult to read hostapd debug log if there is large amount of data
traffic.
This IE is not (at least yet) actually used for anything, but parsing it
cleans up verbose debug log a bit since thie previously unknown, but
commonly used, vendor IE was being reported as unknown.
Only one of the authentication frame types is encrypted. In order for
static WEP encryption to work properly (i.e., to not encrypt the frame),
we need to tell mac80211 about the frames that must not be encrypted.
This allows the same source code file to be shared for both methods. For
now, this is only in eap_aka_prime.c, but eventually, changes in
eap_aka_prime.c are likely to be merged into eap_aka.c at which point
the separate eap_aka_prime.c can be removed.
If the phy info from nl80211 does not include 802.11b mode, generate
that mode based on 802.11g information. This allows hw_mode=b to be used
with drivers that support 2.4 GHz band.
This is just making an as-is copy of EAP-AKA server and peer
implementation into a new file and by using the different EAP method
type that is allocated for EAP-AKA' (50). None of the other differences
between EAP-AKA and EAP-AKA' are not yet included.
It is likely that once EAP-AKA' implementation is done and is found to
work correctly, large part of the EAP-AKA and EAP-AKA' code will be
shared. However, it is not reasonable to destabilize EAP-AKA
implementation at this point before it is clearer what the final
differences will be.
Since the Registrar may not yet know the UUID-E when a new PIN is
entered, use of a wildcard PIN that works with any UUID-E can be useful.
Such a PIN will be bound to the first Enrollee trying to use it and it
will be invalidated after the first use.
If a STA reassociates and changes key_mgmt (e.g., from WPA-PSK to WPS),
hostapd needs to reset some of the existing STA and WPA state machine
variables to allow correct processing for the new association.
Previously, this was only done when the new connection is using
WPA-Personal. However, it looks like it was possible to trigger an
infinite busy loop if altAccept or altReject were left set to true and
an EAPOL frame is received (eapolEap is set to true). Clearing altAccept
and altReject for each association prevents this loop from happening in
the beginning of the next association.
Fragment WPS IE if needed to fit into the IE length limits in hostapd
and Reassemble WPS IE data from multiple IEs in wpa_supplicant.
In addition, moved WPS code from events.c into wps_supplicant.c to clean
up module interfaces.
New control interface commands WPS_PBC, WPS_PIN, and WPS_REG can be used
to start WPS processing. These add and select the WPS network block into
the configuration temporarily, i.e., there is no need to add the WPS
network block manually anymore.
These functions fit in better with the category of functions included in
wps.c. wps_common.c is now used for generic helper functions (currently,
only crypto code).
WPS IE is now passed from hostapd association processing into EAP-WSC
and WPS processing. Request Type attribute is parsed from this
information and if the request is for a WLAN Manager Registrar,
additional management keys are derived (to be used with UPnP).
The wps_context data is now managed at wpa_supplicant, not EAP-WSC. This
makes wpa_supplicant design for WPS match with hostapd one and also
makes it easier configure whatever parameters and callbacks are needed
for WPS.
Previously, wpa_supplicant as Enrollee case was handled using a
different callback function pointer. However, now that the wps_context
structure is allocated for all cases, the same variable can be used in
all cases.
This cleans up the internal interface between different modules and is
the first step in getting wpa_supplicant design closer to hostapd as far
as WPS is concerned.
Previously, hardcoded values were used in wps_enrollee.c. These are now
moved into shared data in struct wps_context. In case of
AP/Authenticator, these are initialized in wps_hostapd.c. In case of
client/supplicant, these are now initialized in EAP-WSC peer method,
but will probably end up being moved into higher layer for better
configuration.
EAP-WSC peer method for
This allows the network to be used after the Registrar configuration
step. The local WPS network is replaced with a new network block
similarly to the case of acting as an Enrollee.
This makes it easier to store old AP settings into wps->cred (and allow
them to modified and taken into use in the future). Separation between
Credential and AP Settings building is also cleaner in this design.
The old (i.e., currently used) AP Settings are processed. For now, they
are copied as-is into M8 as new AP Settings to avoid changing
configuration. This should be changed to allow external programs (e.g.,
GUI) to fetch the old AP settings over ctrl_iface and then allow
settings to be changed before sending M8 with the new settings.
The core processing of attributes into struct wps_credential is now in
wps_common.c (was in wps_enrollee.c), so that the same code can be
shared with Registrar.
