This workaround from commit 6d6f4bb87f ("nl80211: Work around mac80211
limitation on (re)auth when authenticated") pre-dates the code that
supresses the deauth or disconnect event from nl80211. Should this code
be called it would not actually work at this point, as important
internal state for the authentication attempt has already been lost.
Simply drop the code. This might also fix issues where we could get
into a bad state if a proper deauth/disconnect event happens while we
are authenticating or associating.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
With nl80211 we need to supress the kernel generated event for any
disconnect and deauthenticate. This code is a bit fragile, as it
assumes that an event will happen. Commit b898b65582 ("nl80211: Do
not ignore disconnect event in case of !drv->associated") changed this
to only disconnect when the driver knows it is associated (apparently
required for P2P), however, deauthentication may also occur without
being associated yet.
Looking at the issue, what we are really interested in is whether the
event belongs to a disconnect/deauth command that we have send
ourselves. Any event happening after the disconnect/deauth completes
should not be suppressed (or after the next connect/auth as that would
be sufficient). We therefore need to know from the event stream
whether events were generated before or after disconnect/deauth
command completion.
To do so, send a simple command on the nl_event socket. As this will
be returned back to us in the correct order with regard to the events.
We can therefore use it to safely reset our internal
ignore_next_local_{deauth,disconnect} variables.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
With more channels now available in some regulatory domains, some scan
operations can take longer. Give them more time to complete in tests.
For two cases this required adding a timeout parameter to connect(),
which is then passed through.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is needed to avoid NULL pointer deferencing in
wpa_supplicant_ctrl_iface_msg_cb() if any of the functions called from
wpas_bssid_ignore_module_tests_() ends up using wpa_msg().
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Handling of port authorized event for STA currently handles the
connected BSSID. This needs additional handling to support the AP MLD
address in case of MLO connection. The connected_addr expected by
cfg80211_port_authorized() is mld_addr for ML connection case.
Signed-off-by: Vinayak Yadawad <vinayak.yadawad@broadcom.com>
Enable support for ACS in the IEEE 802.11be/320 MHz case. To do so we
just:
- add channel definitions for the 320 MHz blocks of the 6 GHz band
- handle CONF_OPER_CHWIDTH_320MHZ in the different cases
- restrict 320 MHz to ieee80211be=1 only
Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
Fix for the HE Channel Center Freq Seg0/Seg1 within the HE 6GHz
Operation Information field. As downgrade of bandwidths for VHT and HE
when using puncturing is TODO for 320 MHz and/or if puncturing is
disabled and bandwidth is 320 MHz, the same rules as for 160 MHz should
be applied for Channel Center Freq Seg0/Seg1 within 6 GHz Operation
Information field.
Signed-off-by: Jurijs Soloveckis <jsoloveckis@maxlinear.com>
Include EHT Operation Information field only if the operating bandwidth
is 320 MHz or there is at least one punctured 20 MHz subchannel. This
behavior is defined in IEEE P802.11be/D4.0, 35.15.1 (Basic EHT BSS
operation).
Signed-off-by: Jurijs Soloveckis <jsoloveckis@maxlinear.com>
The prime_len variable is used as the length in bytes but it is set as
the length in bits. This fixes the sae DH group tests with wolfSSL.
Fixes: f8f20717f8 ("SAE: Use const_time selection for PWE in FFC")
Signed-off-by: Juliusz Sosinowicz <juliusz@wolfssl.com>
MBSSID shares a single Beacon frame with multiple BSSs. This implies
that the key used for beacon protection (BIGTK) needs to be shared. The
nontransmitted BSSs managed their own BIGTK previously and that resulted
in providing incorrect value to the stations associated with those BSSs.
Use the BIGTK from the transmitted BSS to fix this.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Test functionality in cases where MBSSID is used with a WPA2-Personal
only BSS as the transmitted BSS and WPA3-Personal BSS as the
nontransmitted BSS.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Order scan results in a manner that prefers BSSs that support SAE over
ones that support PSK without SAE if the SNR of the SAE BSS is good or
at least at the same level as the SNR for the PSK BSS. This improves
likelihood of using SAE when the local network profile allows
WPA3-Personal transition mode and the ESS uses a mix BSSs with different
sets of AKMs.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Extend the optimization from commit 9c97126576 ("OWE: Optimize
transition mode scan to use known channels") to cover cases where the
STA is configued with OWE transition mode disabled, but the AP uses OWE
transition mode.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
BSS table is not updated when a non-P2P station runs a scan without P2P
IE in Probe Response frame, since that would remove P2P IE information.
However, this results also in not updating mandatory rates in Supported
Rates and BSS Membership Selectors element even though AP/GO changes
frequency from 2.4 GHz to 5 GHz band.
This is causing connection failure since BSS table has 1 Mbps as
mandatory rate for AP connection but minimum supported rate in 5 GHz
band is 6 Mbps.
To avoid connection failures in such cases, don't skip updating BSS
table when the BSS frequency is changed. This covers the most important
case addressed in commit ff57398fca ("P2P: Do not drop P2P IEs from
BSS table on non-P2P scans") while still allowing other changes to be
taken into account if the GO were to actually change channels (or band,
which would be the most likely case needing the update).
Signed-off-by: Ainy Kumari <quic_ainykuma@quicinc.com>
Fix references to the appropriate driver capability drv_flags2. The
initial version used the incorrect drv_flags value and by doing so,
ended up using incorrect driver capabilities (DEAUTH_TX_STATUS,
BSS_SELECT, TDLS_SUPPORT) which could result in incorrect OWE
functionality for both AP and STA cases.
Fixes: d984c7b298 ("hostapd: Add support for OWE offload for STA/AP interface")
Fixes: da364180fb ("hostapd: Support 4-way handshake offload for AP/P2P GO")
Signed-off-by: Vinayak Yadawad <vinayak.yadawad@broadcom.com>
Otherwise the station or AP might be doing router advertisements,
causing keep alive already without the mechnism that is being tested.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
The openssl_ciphers parameter is a global data entry on the server
instead of the per-connection design on client. As such, hostapd needs
to make a local copy of the global value and use that whenever setting
per-connection parameters. This is needed particularly when testing
Suite B functionality where the Suite B specific parameters might end up
overriding the cipher list.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Define a new command QCA_TSF_SYNC_GET_CSA_TIMESTAMP in qca_tsf_cmd to
retrieve the TSF time value at which the AP will move and starts
beaconing on a new channel. Userspace queries this TSF after receiving
NL80211_CMD_CH_SWITCH_STARTED_NOTIFY event on the AP interface. This TSF
can be communicated via an OOB mechanism to connected STAs which may
fail to receive the CSA frames due to channel congestion.
Signed-off-by: Purushottam Kushwaha <quic_pkushwah@quicinc.com>
If the local network profile specifies a specific BSSID, there will not
be an acceptable alternative AP for the current one. As such, there is
not much point in trying to scan and wait for the results to make this
conclusion. Skip the scan and reject the BSS transition management
request even if that ends up getting disassociated from the BSS that
happens the be the only one that the local configuration allows to be
used.
Signed-off-by: Jouni Malinen <j@w1.fi>
The driver advertising SAE AP offload support would take care of SAE
authentication and PMK generation at the driver/firmware. This feature
requires the driver to be supporting 4-way handshake offload to process
the generated PMK at the driver level for 4-way handshake.
Signed-off-by: Vinayak Yadawad <vinayak.yadawad@broadcom.com>
The driver advertising OWE offload support would take care of
Diffie-Hellman Parameter element generation and processing part. The
driver would be responsible for OWE PMK generation in this case.
Avoid the Diffie-Hellman Parameter element handling in
wpa_supplicant/hostapd for drivers advertising OWE offload support. This
change is applicable only for drivers supporting 4-way handshake
offload.
Signed-off-by: Vinayak Yadawad <vinayak.yadawad@broadcom.com>
Add support for offloaded 4-way handshake in AP/P2P GO mode. For drivers
supporting the AP PSK offload, wpa_supplicant/hostapd passes down the
PSK for the driver to handle the 4-way handshake. The driver is expected
to indicate port authorized event to indicate that the 4-way handshake
is completed successfully.
Signed-off-by: Vinayak Yadawad <vinayak.yadawad@broadcom.com>
The max transmit power of Standard Power (SP) Access Points (AP) on
6 GHz band and APs on 2.4 GHz and 5 GHz bands is limited by effective
isotropic radiated power (EIRP), while the max transmit power of Low
Power Indoor (LPI) APs on 6 GHz Band is limited by power spectral
density (PSD). Therefore the max transmit power of LPI APs grows as the
channel width increases, similar to the noise power which has constant
PSD.
Adjust the RSSI, SNR and throughput estimate based on max transmit power
config and max channel width in the roaming algorithm.
Signed-off-by: Kaidong Wang <kaidong@chromium.org>
The max transmit power of Standard Power (SP) Access Points (AP) on
6 GHz band and APs on 2.4 GHz and 5 GHz bands is limited by effective
isotropic radiated power (EIRP), while the max transmit power of Low
Power Indoor (LPI) APs on 6 GHz Band is limited by power spectral
density (PSD). Therefore the max transmit power of LPI APs grows as the
channel width increases, similar to the noise power which has constant
PSD.
Adjust the SNR of BSSes based on the transmit power config and max
channel width. EIRP limited APs usually have constant max transmit power
on different channel widths, their SNR decreases on larger channel width
because the noise power is higher, while PSD limited APs have constant
SNR over all channel widths.
Signed-off-by: Kaidong Wang <kaidong@chromium.org>
With the SSID updating of a BSS entry removed from owe_trans_ssid(),
this call to owe_trans_ssid() is not really doing anything, so remove
it. This reverts 6972b0fa2b ("OWE: Update transition mode information
on selecting a new BSS").
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Overwriting of SSID for the hidden OWE BSS entry has some side effects:
- first the entry is notified over DBus with empty SSID and the update
of SSID is never signaled (it is not even possible at the moment to
notify the SSID change - see wpas_dbus_bss_signal_prop_changed()),
- during (and after) association there will be multiple entries
referring to the same BSSID/SSID pair.
Stop overwriting the SSID in an existing BSS entry based on OWE
transition mode information. Instead, depend on a new BSS entry getting
added for the hidden OWE BSS based on active scans for the SSID learned
from the open BSS. This would not have been sufficient for the initial
OWE design, but with the optimized scanning behavior from commit
c04562e67e ("OWE: Improve discovery of OWE transition mode AP"), this
can now depend on the exact same mechanism as other uses of hidden
SSIDs. This helps in keeping the D-Bus interface in sync with the BSS
parameters.
Signed-off-by: Andrzej Ostruszka <andrzejo@chromium.org>
If the currently available scan results include OWE transition mode BSS
with an unknown SSID, optimize the following scan for OWE to use only
the channels on which a known transition mode BSS has been seen.
This is needed to be able to remove the design that updates BSS entries
with the learned OWE SSID in manner that does not result in regression
to scanning latencies.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The local network profile may not have matching SSID (it could be either
the wildcard 0-length SSID or visible SSID in case of OWE transition
mode), so check whether an exact match with a BSS entry can be made
using the current SSID information from the driver (i.e., the SSID of
the current association) when picking the BSS entry to use as the
current one for an association.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Use the Same SSID and Colocated AP bits as an alternative way of finding
a match on the current SSID.
Signed-off-by: Ben Greear <greearb@candelatech.com>
The Reduced Neighbor Report element can include one or more TBTT
Information fields. Only the first one was parsed previously. Extend
this to use a loop to go through all included TBTT Information fields.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Beacon frames are allowed to optionally include one more more Reduced
Neighbor Report elements. Only the first one was parsed previously.
Extend this to use a loop to go through all included RNR elements.
Signed-off-by: Ben Greear <greearb@candelatech.com>
The driver is expected to update the DTIM Count field for each BSS that
corresponds to a nontransmitted BSSID. Initialized this value to 0 in
the Beacon frame template so that the DTIM count would be somewhat
functional even if the driver were not to update this.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
In case of low-memory conditions, the computation for legendre symbol
can fail and return -2 as per documentation, but the check for that
was missed here. And this can can cause an infinite loop searching for
qr and qnr if the error repeats for each attempt.
Break the loop if calculation fails, we can leave retry to the callers
or user. This is similar to the way allocation and generation of a new
random number was handled in this loop.
Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
Currently the documentation for QCA_WLAN_VENDOR_ATTR_CONFIG_MLO_LINK_ID
indicates it is only for use inside nest attribute
QCA_WLAN_VENDOR_ATTR_CONFIG_MLO_LINKS. Update the documentation to
allow it to be used outside that nest as well.
Signed-off-by: Mohan Prabu <quic_mprabub@quicinc.com>
Also this EAPOL frame uses the MLD MAC address of the AP MLD when sent
during an MLO association.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
For MLO association, specify destination address as the MLD MAC address
for sending Group Key msg 2/2.
Signed-off-by: Rohan Dutta <quic_drohan@quicinc.com>
Leverage the already available control socket cmd "DRIVER_FLAGS2" and
dump the driver capab "flags2" bitmask on triggering the new CLI CMD
"driver_flags2", similar to the already existing CLI CMD "driver_flags".
$ hostapd_cli -i wlan0 driver_flags2
(OR)
$ wpa_cli -i wlan0 driver_flags2
0000000000000020:
BEACON_RATE_HE
Signed-off-by: Gokul Sivakumar <gokulkumar.sivakumar@infineon.com>
This adds the newer driver capability "flags2" bitmask to the
hostapd_cli/wpa_cli "status driver" result.
Signed-off-by: Gokul Sivakumar <gokulkumar.sivakumar@infineon.com>
This was already done for driver_flags, but the newer driver_flags2 was
not covered here.
Signed-off-by: Gokul Sivakumar <gokulkumar.sivakumar@infineon.com>
Populate the switch case in the driver_flag2_to_string() function with
the full list of feature MACROs represented with the "flags2" bitmask.
Signed-off-by: Gokul Sivakumar <gokulkumar.sivakumar@infineon.com>
