Code for connecting/reconnecting to the hostapd control interface
is found duplicated a number of times. Create a common reconnect
helper function to avoid code duplication.
Signed-off-by: Mikael Kanstrup <mikael.kanstrup@sonymobile.com>
Whenever reconnecting the control interface the hostapd station list
is unknown as stations might have dropped or connected. Refresh the
list of stations used for command completion on cli connect, reconnect
and interface change.
Signed-off-by: Mikael Kanstrup <mikael.kanstrup@sonymobile.com>
As hostapd_cli now supports command completion add documentation
of the config option to defconfig. Disabled per default.
Signed-off-by: Mikael Kanstrup <mikael.kanstrup@sonymobile.com>
With mac_addr=0 and preassoc_mac_addr=1, the permanent MAC address
should be restored for association. Previously this did not happen when
reassociating to the same ESS.
Signed-off-by: Benjamin Richter <br@waldteufel.eu>
Scan results were not propagated to all interfaces if scan results
started a new operation, in order to prevent concurrent operations. But
this can cause other interfaces to trigger a new scan when scan results
are already available. Instead, always notify other interfaces of the
scan results, but note that new operations are not allowed.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
There are a couple of places in wpa_supplicant/hostapd where qsort() can
be called with a NULL base pointer. This results in undefined behavior
according to the C standard and with some standard C libraries (ARM RVCT
2.2) results in a data abort/memory exception. Fix this by skipping such
calls since there is nothing needing to be sorted.
Signed-off-by: Joel Cunningham <joel.cunningham@me.com>
This was already done for most driver cases, but it is possible that the
BSSID/frequency is not forced if the driver reports BSS selection
capability (e.g., NL80211_ATTR_ROAM_SUPPORT). That could potentially
result in the driver ignoring the BSSID/frequency hint and associating
with another (incorrect) AP for the WPS provisioning step if that
another AP in the same ESS is more preferred (e.g., better signal
strength) by the driver and only one of the APs (the not preferred one)
is in active WPS registrar state.
While most drivers follow the BSSID hint for the initial connection to
an ESS, not doing it here for the WPS provisioning would break the
protocol. Fix this by enforcing a single BSSID/frequency to disallow the
driver from selecting an incorrect AP for the WPS provisioning
association.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
That function does not need the full EAP header -- it only needs to know
which EAP identifier to use in the message. Make this usable for cases
where the previous EAP message may not exist (FILS).
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This changes 4-way handshake authenticator processing to decrypt the
EAPOL-Key frames using an AEAD cipher (AES-SIV with FILS AKMs) before
processing the Key Data field. This replaces Key MIC validation for the
cases where AEAD cipher is used.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This changes 4-way handshake authenticator processing to decrypt the
EAPOL-Key frames using an AEAD cipher (AES-SIV with FILS AKMs) before
processing the Key Data field. This replaces Key MIC validation for the
cases where AEAD cipher is used. This needs to move the EAPOL-Key msg
2/4 RSN element processing to happen only after the PTK has been derived
and validated. That is done for all AKMs to avoid extra complexity with
having to maintain two code paths for this.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This modifies wpa_eapol_key_send() to use AEAD cipher (AES-SIV for FILS
AKMs) to provide both integrity protection for the EAPOL-Key frame and
encryption for the Key Data field. It should be noted that this starts
encrypting the Key Data field in EAPOL-Key message 2/4 while it remains
unencrypted (but integrity protected) in non-FILS cases. Similarly, the
empty Key Data field in EAPOL-Key message 4/4 gets encrypted for AEAD
cases.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This will be needed to be able to implement AEAD cipher support from
FILS that will need to use KEK to protect the frame.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The new AEAD AKM option in FILS sets the MIC bit in EAPOL-Key frames to
0 for some ciphers, so the determination of EAPOL-Key frame types needs
changes to work with these cases.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Suite B 192-bit addition from IEEE Std 802.11ac-2013 replaced the
previous fixed length Key MIC field with a variable length field. That
change was addressed with an addition of a new struct defined for the
second MIC length. This is not really scalable and with FILS coming up
with a zero-length MIC case for AEAD, a more thorough change to support
variable length MIC is needed.
Remove the Key MIC and Key Data Length fields from the struct
wpa_eapol_key and find their location based on the MIC length
information (which is determined by the AKMP). This change allows the
separate struct wpa_eapol_key_192 to be removed since struct
wpa_eapol_key will now include only the fixed length fields that are
shared with all EAPOL-Key cases in IEEE Std 802.11.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Calculate the hashed realm from hostapd erp_domain configuration
parameter and add this to the FILS Indication element when ERP is
enabled.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This can be used to check whether the running wpa_supplicant version was
built with CONFIG_FILS=y.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
If FILS is supported, indicate that in Probe Request and (Re)Association
Request frames in the Extended Capabilities element.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
If FILS is enabled, indicate that in Beacon, Probe Response, and
(Re)Association Response frames in the Extended Capabilities element.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This adds CONFIG_FILS=y build configuration option and new key
management options for FILS authentication.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This adds CONFIG_FILS=y build configuration option and new key
management options for FILS authentication.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This adds definitions for new information elements from P802.11ai/D11.0
and parsing of these IEs.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The extension of aes_128_ctr_encrypt() to allow AES-192 and AES-256 to
be used in addition to AES-128 for CTR mode encryption resulted in the
backtrace for the function calls changing. Update the test cases that
started failing due to that change.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The previous implementation was hardcoded to use 128-bit AES key
(AEAD_AES_SIV_CMAC_256). Extend this by allowing AEAD_AES_SIV_CMAC_384
and AEAD_AES_SIV_CMAC_512 with 192-bit and 256-bit AES keys.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This allows the CRC-32 routine to be shared for other purposes in
addition to the WEP/TKIP/FCS within wlantest.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Station should be able to connect initially without ft_pmk_cache filled,
so the target AP has the PSK available and thus the same information as
the origin AP. Therefore neither caching nor communication between the
APs with respect to PMK-R0 or PMK-R1 or VLANs is required if the target
AP derives the required PMKs locally.
This patch introduces the generation of the required PMKs locally for
FT-PSK. Additionally, PMK-R0 is not stored (and thus pushed) for FT-PSK.
So for FT-PSK networks, no configuration of inter-AP communication is
needed anymore when using ft_psk_generate_local=1 configuration. The
default behavior (ft_psk_generate_local=0) remains to use the pull/push
protocol.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
This also implements the macsec_get_capability for the macsec_qca
driver to maintain the existing behavior.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
RFC 5931 Section 2.8.5.1 does not list the Prep field as something that
the server validates to match the Request. However, the supplicant side
has to use the same pre-processing mechanism for the password for the
authentication to work, so we may as well as enforce this field to match
the requested value now that wpa_supplicant implementation is fixed to
copy the value from the request.
Signed-off-by: Jouni Malinen <j@w1.fi>
