cfg80211 requires the link ID to be specified for requests to start a
remain-on-channel operation during an ML association. This feels wrong
since the ROC operation is in most cases unrelated to the
association. However, that requirement has been in place since kernel
commit 7b0a0e3c3a88 ("wifi: cfg80211: do some rework towards MLO link
APIs") from April 2022, and as such, it looks necessary to have
wpa_supplicant work around this by specifying the currently used link ID
that would seem to match the ROC channel most closely.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The GAS request may have been issued using a link address of the AP
MLD's affiliated link and the driver may translate that address to the
MLD MAC address when associated with the AP MLD. Accept GAS responses
where the addresses map to the same AP MLD.
Signed-off-by: Jouni Malinen <j@w1.fi>
The target MAC address needs to be checked against all the AP MLD link
addresses and the MLD MAC address to cover all possible cases. This is
needed to be able to correctly use Protected Dual of Public Action
frames during an ML association.
Signed-off-by: Jouni Malinen <j@w1.fi>
Commit 31e025c033 ("AP: When sending Action frames, use the AP MLD MAC
address if needed") added this for hostapd_drv_send_action(), but the
A3=BSSID variant of that function needs similar changes for GAS to work
correctly with STAs that are currently associated with MLO.
Signed-off-by: Jouni Malinen <j@w1.fi>
Invert the check on hapd->conf->mld_ap on the affiliated links to
actually call the link specific callback handler. This is needed to set
the STA associated.
Fixes: 55038680a6 ("AP: MLO: Handle association callback")
Signed-off-by: Jouni Malinen <j@w1.fi>
This is needed to allow RSN operations, like PTK rekeying, to be
completed on the correct STA entry. The previous design worked by
accident since it was using the WLAN_STA_ASSOC flag and the code that
was supposed to set that flag did not work correctly and left it unset
for the interfaces that were not used for the initial 4-way handshake.
That needs to be fixed, so this search need to be extended to be able to
prefer the STA entry that has sta->wpa_sm set instead of just the
WLAN_STA_ASSOC flag.
Signed-off-by: Jouni Malinen <j@w1.fi>
The change to use a helper function for checking he_6ghz_reg_pwr_type
missed the difference between two types of checks for different values:
indoor AP vs. SP AP. Fix this by introducing another helper function to
cover the indoor (i.e., SP and non-SP indoor cases).
Fixes: 121ccadeb4 ("AP: A helper function for determining whether the AP is an SP AP")
Signed-off-by: Jouni Malinen <j@w1.fi>
The current operating channel bandwidth in an HE BSS is determined with
the combination of elements, include the VHT Operation element. Use VHT
Operation element to check whether the 80, 80+80, and 160 MHz cases are
enabled if the AP claims to be capable of operating an 80/160 MHz BSS.
Signed-off-by: Jouni Malinen <j@w1.fi>
The current operating channel bandwidth in an HE BSS is determined with
the combination of elements, include the HT Operation element. Use HT
Operation element to check whether the 40 MHz case is enabled if the AP
claims to be capable of operating a 40 MHz BSS.
Signed-off-by: Jouni Malinen <j@w1.fi>
There are bandwidth 320 MHz-1 and 320 MHz-2 channelization in EHT mode.
When using ACS, user might prefer one of the channelization or both, but
original ACS was unable to take such preference.
Another problem is that the original ACS returns only the ideal channel
but no 320 MHz channelization. The function acs_get_bw_center_chan()
also could not correctly return the center frequency of bandwidth 320
MHz that is decided by ACS.
For example, if ACS decide the ideal channel is channel 37 with
channelization 320 MHz-2 (center frequency 6265 MHz),
acs_get_bw_center_chan() returns 6105 MHz, which is 320 MHz-1.
Extend the support for 320 MHz so that ACS can choose the best channel
according to the user's preference. Also, after calling
acs_find_ideal_chan_mode(), the best channel and bandwidth can be
derived.
The changes are:
- bw_type ACS_BW320 is divided into ACS_BW320_1 and ACS_BW320_2
- in bandwidth 320 MHz, find the best channel and bandwidth according to
user's perference (320 MHz-1, 320 Mhz-2 or both are OK)
- before acs_find_ideal_chan_mode() returns, update bw320_offset in
iface->conf so that the best channel's channelization is recorded.
- get the best center frequency from bw320_offset
Co-developed-by: Money Wang <money.wang@mediatek.com>
Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com>
Introduce a new configuration option, "eht_bw320_offset", which enables
devices to specify a preferred channelization for 320 MHz BSSs when
using automatic channel selection (ACS). This option is applicable only
when the channel is not already decided and the bandwidth is set to 320
MHz.
The value and meaning of the option:
0: auto-detected by ACS
1: 320 MHz-1
2: 320 MHz-2
Co-developed-by: Money Wang <money.wang@mediatek.com>
Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com>
Fix the following bugs about selecting the best channels in the segment:
1. If the 'update_best' once became false, it never becomes true again.
In other word, if one of the channels in the segment is not usable,
the remaining channels in the segment were never able to be the best
channel.
2. The primary channel in the segment might not be usable due to the
insufficient survey data. Therefore, it cannot be the best channel and
we cannot take its factor/weight into account.
Co-developed-by: Money Wang <money.wang@mediatek.com>
Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com>
Extend the previously used minimal test case with full validation of the
selected channel and connection since hostapd now has support for the
HT40- case as well.
Signed-off-by: Jouni Malinen <j@w1.fi>
Allow ACS to pick a HT40- channel in the 2.4 GHz band in addition to the
previously hardcoded HT40+ case.
Co-developed-by: Money Wang <money.wang@mediatek.com>
Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com>
With UML time-travel, it was possible for a GAS frame to end up in the
capture file for the next test case and if that next case used tshark to
count the number of frames (which is done, e.g., in
gas_anqp_address3_assoc), the following test case could have indicated
failure even when everything worked correctly.
Signed-off-by: Jouni Malinen <j@w1.fi>
Use the PHY parameters from configuration or the values passed in from
the dbus API for P2P dbus command GroupAdd instead of using the hard
coded values to be inline with the method provided with the
wpa_supplicant control interface.
Signed-off-by: Jintao Lin <jintaolin@chromium.org>
The vht_center_freq2 parameter was in incorrect order in the call to
wpas_p2p_group_add_persistent(). This would have dropped the value when
adding a group based on a previously created persistent group ion the GO
side and that would have resulted in a failure to start the GO.
Fix the function call to use the correct order for the parameters.
Signed-off-by: Jintao Lin <jintaolin@chromium.org>
This allows the function to be used outside the context of the
wpa_supplicant control interface implementation.
Signed-off-by: Jintao Lin <jintaolin@chromium.org>
When the P2P persistent group is provisioned out-of-band, i.e., add
persistent group with a known BSSID, SSID, passphrase, and frequency,
and start the group with GroupAdd dbus command, the group info fetched
on the cliend side has zero MAC address for BSSID and no value for
frequency. Fix this issue by getting that information from
wpa_s->current_bss instead of wpa_s->go_params.
Signed-off-by: Jintao Lin <jintaolin@chromium.org>
Previously only the SHA-1 -based AKM was supported. Extend that to cover
all PSK AKMs so that the PSK configuration to the driver happens for all
the possible cases during AP start.
Signed-off-by: Vinayak Yadawad <vinayak.yadawad@broadcom.com>
The cfg80211 default QoS mapping might be updated to align with the
recommendations in section 4 in RF C8325. Align the QoS mapping tests
accordingly. For now, allow both the previous and new mapping to pass
the test.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
If the regulatory client EIRP PSD values advertised by an AP that is a
standard power AP or indoor standard power AP are insufficient to ensure
that regulatory client limits on total EIRP are always met for all
transmission bandwidths within the bandwidth of the AP’s BSS, the AP
shall also send a TPE element in Beacon and Probe Response frames as
that depicts the regulatory client EIRP limit.
Add support for this.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
According to IEEE P802.11-REVme/D4.0, E.2.7 (6 GHz band), two Transmit
Power Envelope (TPE) elements need to be included by Indoor Standard
Power (Indoor SP) APs. Extend the code to support this.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
According to IEEE P802.11-REVme/D4.0, 9.4.2.169.2 (Neighbor AP
Information field), the 20 MHz PSD subfield in the TBTT Information
field is a signed value with valid range of -127 to +126, while +127
indicates "no maximum transmit power is specified". Fix the default
value advertised.
Fixes: 3db24e4eef ("RNR: Define element format")
Fixes: a7c152d6b8 ("RNR: Add data from neighbor database")
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Add a simple test that exemplifies TX power configuration when operating
on the 6 GHz band.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Add configuration options for setting the Tx Power value
in the Transmit Power Envelope for 6 GHz:
- The Tx power value for default client where the transmit
power interpretation is "Regulatory Client EIRP PSD"
- The Tx power value for subordinate client where the transmit
power interpretation is "Regulatory Client EIRP PSD"
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Update the HE regulatory information AP types based on IEEE
P802.11-REVme/D4.0. Set the default AP type to VLP. Check for valid
values when setting 'he_6ghz_reg_pwr_type' in the interface
configuration.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
The location of the comment is incorrect and it is not really needed.
Remove it.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
We only print the newline if the AP MLD ID is present
(BASIC_MULTI_LINK_CTRL_PRES_AP_MLD_ID), fix that.
Fixes: e3e68668c1 ("ctrl_iface: Report RNR and ML in BSS command")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
It is not really helpful to get debug prints about Hotspot 2.0 frame
filtering when trying to connect a non-Hotspot 2.0 network. Remove this
debug print that was being printed for every connection that did not use
Hotspot 2.0.
Signed-off-by: Jouni Malinen <j@w1.fi>
In cases of SAE failure and testing, mgmt->sa was used for sending the
Authentication frame. Fix these to use the station address (which is
the MLD MAC address in cases of non-AP MLDs).
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Add a testing configuration such that the AP would be reported as
disabled in the RNR TBTT information MLD parameters included by other
affiliated APs of the AP MLD.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
An affiliated AP of an AP MLD can temporarily be disabled. Other
affiliated APs of the AP MLD indicate this in the Reduced Neighbor
Report (RNR) elements added to their Beacon and Probe Response frames.
When an affiliated AP is disabled, it should be included in the
association exchange, but can be activated only after it is enabled.
Add support identifying disabled APs and propagate the information
to the driver within the associate() callback.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
