For a memory constrained system, it may be more important to reduce
binary size than include support for these capabilities.
By default this is enabled.
Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
For a memory constrained system, it may be more important to reduce
binary size than include support for these capabilities.
By default this is enabled.
Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
Removing radio measurements and supported operating class indication
might be needed to reduce binary size for a memory constrained system
that does not need more advanced features. However, removing these is
not recommended since they can help the AP manage the network and STA
steering.
By default this functionality is enabled.
Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
Parse the link status values out of Multi-Link association response. If
the AP rejects ML association and marks the links as failed with a
reason code other than TX_LINK_NOT_ACCEPTED, also report these links to
wpas_connection_failed() and ignore them.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.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>
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>
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>
Prevent loading arbitrary executable code based on config at runtime,
while allowing libraries to be specified at compile time when they are
known in advance.
Add the ability to configure libraries to load at compile time.
* CONFIG_PKCS11_ENGINE_PATH - pkcs11_engine library location.
* CONFIG_PKCS11_MODULE_PATH - pkcs11_module library location.
* CONFIG_OPENSC_ENGINE_PATH - opensc_engine library location.
Add flags with the ability to set each of the libraries to NULL and
prevent loading them at runtime.
* CONFIG_NO_PKCS11_ENGINE_PATH - prevents loading pkcs11_engine
library.
* CONFIG_NO_PKCS11_MODULE_PATH - prevents loading pkcs11_module
library.
* CONFIG_NO_OPENSC_ENGINE_PATH - prevents loading opensc_engine
library.
* CONFIG_NO_LOAD_DYNAMIC_EAP - prevents loading EAP libraries at
runtime.
Signed-off-by: David Ruth <druth@chromium.org>
Add support for Authentication negotiated over IEEE Std 802.1X
with key derivation function using SHA-384.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
When channel 140 is configured in mesh, interface fails to come up due
to channel bond (136,140). Since Channel 136 is not HT40+ capable,
validation for HT channel bonding fails when it checks whether first
channel in the bond (channel 136) is HT40+ capable.
In mesh, during channel setup, secondary channel offset for the
configured channel will be selected as +1 if primary channel is capable
of HT40+. In current code, channel 140 is not allowed as HT40+ and hence
secondary channel offset is selected as -1, which makes 136 as secondary
channel. But channel 136 is not HT40+ supported and fails in channel
bonding validation.
Add 140 to HT40+ allowed list as HT40+ is supported for the channel.
Signed-off-by: Ramya Gnanasekar <quic_rgnanase@quicinc.com>
Pointer entry->ssid might be passed to owe_trans_ssid_match() function
as argument 3 with NULL value, and it may be dereferenced there. This
looks like a theoretical case that would not be reached in practice, but
anyway, it is better to check entry->ssid != NULL more consistently.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Since wpa_supplicant version 2.10 the extended capabilities MSCS and SCS
are advertised in the (Re)Association Request frames.
This causes the association request to be rejected by several access
points. Issue was observed with:
- D-Link DIR600
- TP-Link AC1900
- Synology MR2200ac
To avoid this issue the extended capabilities MSCS and SCS shall only be
added if the bss also supports them. While this may not follow the exact
behavior described in IEEE 802.11, this is a reasonable compromise to
avoid interoperability issues since these capabilities cannot be used
with an AP that does not support them anyway.
Note: The Extended Capabilities element is only included in the
Association Request frames if the AP also sent its extended capabilities
(see wpas_populate_assoc_ies()) as a workaround for misbehaving APs.
This workaround exists since version 2.1.
Signed-off-by: Sebastian Priebe <sebastian.priebe@konplan.com>
Store 6 GHz capability on channel list update for wpa_supplicant use.
This will be used in the next commit to extend scanning behavior based
on changes to 6 GHz channel availability.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
Add support for building and sending ML probe requests. During connect,
try to send an ML probe request if we are going to connect to an MLD AP
and the BSS information for some of the links is missing.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Along with canceling queued scan, abort ongoing scan if any, this
ensures Wi-Fi interface is in usable state after disconnect is issued,
else subsequent scan after disconnect might fail with EBUSY.
Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
wpa_supplicant postpones expired PMKSA deletion untillassociation is
lost for SAE to avoid forced disconnection. But during this time the
driver may use the expired PMKSA for reassociation with the current
connected AP.
Remove the current PMKSA for SAE from the driver after reauth threshold
is passed when the driver takes care of BSS selection.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Do not reject reauth threshold passed PMKSA indicated in successful
association event since the PMKSA is still valid.
Additionally, remove the reauth threshold passed PMKSA entry from the
driver to prevent using it further in the driver.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Send the actual MFP configuration value to the driver instead of
overriding it with MFP required based on the wpa_supplicant selected BSS
when the driver takes care of BSS selection.
This is needed to allow the driver to know whether it can select an MFP
disabled BSS.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Set WFA capability to allow non-EHT SCS Traffic support in association
elements when the AP advertises support for non-EHT SCS Traffic support
via Beacon or Probe Response frame. This capability is upper layer
functionality and as such, does not need a separate driver capability
indication or configuration, but indicate this only if the AP supports
the feature to minimize risk of interoperability issues with a new
information element.
Signed-off-by: Purushottam Kushwaha <quic_pkushwah@quicinc.com>
The Linux kernel expects to use the AP MLD address in
NL80211_ATTR_PREV_BSSID for reassociation requests when the current
association is MLO capable.
Previously, wpa_supplicant was using the BSSID value in
NL80211_ATTR_PREV_BSSID even if the connection is MLO capable. Fix this
by sending the AP MLD address in NL80211_ATTR_PREV_BSSID for
reassociation requests when MLO is used.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
When starting a new BSS as AP mode, the network configs have been passed
in from the BSS config. There is no need to scan before creating a new
BSS. Reuse connect_without_scan structure member to bypass scan when the
mode is WPAS_MODE_AP.
Signed-off-by: Jintao Lin <jintaolin@chromium.org>
In theory, each device that supports WMM (or the IEEE 802.11 QoS for
that matter) is expected to advertise how many replay counters it
supports and the peer device is supposed to use that information to
restrict the total number of different MSDU priorities (AC/UP) that
might be used. In practice, this is not really done in deployed devices
and instead, it is just assumed that everyone supports the eight
different replay counters so that there is no need to restrict which
MSDU priorities can be used.
hostapd implementation of WMM has advertised support for 16 PTKSA replay
counters from the beginning while wpa_supplicant has not had any code
for setting the supported replay counter fields in RSNE, i.e., has left
the value to 0 which implies that only a single replay counter is
supported. While this does not really result in any real issues with
deployed devices, this is not really correct behavior based on the
current IEEE 802.11 standard and the WMM specification.
Update wpa_supplicant to use similar design to the hostapd RSNE
generation by setting the number of supported PTKSA replay counters to
16 whenever WMM is enabled. For now, this is done based on the
association being for HT/VHT/HE/EHT and also based on the AP supporting
WMM since it is much more likely for the local device to support WMM and
eight replay counters (which can be indicated only with the value that
implies support for 16 counters since there is no separate value for 8).
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Add the channels 165 and 173 in allowed channels for ht40_plus. Also add
the allowed frequency 5825 (channel 165; channel center frequency index
171) for 80 MHz bandwidth.
Signed-off-by: Seevalamuthu Mariappan <quic_seevalam@quicinc.com>
Signed-off-by: Raj Kumar Bhagat <quic_rajkbhag@quicinc.com>
The STATUS command showed the interface state as SCANNING even if mesh
bringup fails. This incorrect interface status can mislead
scripts/applications that rely on interface status to bring up different
type of virtual interfaces (AP/MESH) on a single radio.
Fix this by setting the interface status as INACTIVE if mesh bringup
fails.
Signed-off-by: Hari Chandrakanthan <quic_haric@quicinc.com>
Add mesh_eht_enabled and eht ssid configuration parameters to include
EHT Capability and EHT Operation elements in mesh PLINK Action frames.
Update mesh_eht_enabled from EHT capability advertised for mesh mode.
Signed-off-by: Sathishkumar Muruganandam <quic_murugana@quicinc.com>
Signed-off-by: Ramya Gnanasekar <quic_rgnanase@quicinc.com>
- Do not try to enable 80 MHz if 40 MHz is disabled or not selected (e.g.,
due to obss_scan).
- If it is not possible to use 80 HMz or even 40 MHz, still attempt to
configure HE40/VHT40/HE20/VHT20 instead of bailing out.
- When bailing out, also disable HE.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
If the PHY supports both 5 GHz and 6 GHz bands, there will be two
different struct hostapd_hw_modes with mode HOSTAPD_MODE_IEEE80211A,
one for each band, with potentially different capabilities.
Check that the struct hostapd_hw_modes actually contains the frequency
before selecting it.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
ibss_mesh_setup_freq() has become a 342 line function with 23 local
variables, 1 or 2 goto labels depending on ifdefs and its logic is
quite unpredictable.
Split it into multiple functions. No functional change intended, it
should be bug-compatible with the original code, except for some log
messages that are skipped more often.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
The previous implementation handles PMKSA cache attempts with AP MLD
address only for SME-in-wpa_supplicant cases since wpa_s->valid_links
wouldn't be set for SME-in-driver cases.
Fix SME-in-driver behavior by enabling PMKSA cache attempts with AP MLD
address when driver supports MLO and SME offload to driver.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
It was possible to hit a case where the SAE PT had not yet been derived,
e.g., when using P2P group re-invocation. Update PT use at the time
authentication is started, if needed, to avoid this. While this is not
really ideal from the externally observable timing view point, this is
done only for the case where there is no other option available with a
dynamically changing network configuration for P2P. Similar design was
already in place for the SAE offload-from-driver (external auth) case.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
IEEE Std 802.11ax-2021, 12.12.2 requires this, so force MFPR=1 when
associating on the 6 GHz band so that ieee80211w=1 (i.e., MFPC=1 MFPR=0)
configuration can be used to get MFPC=1 behavior on other bands and
MFPR=1 on the 6 GHz band.
Signed-off-by: Jouni Malinen <j@w1.fi>
Now that we check in PMKSA cache code whether the entry was created for
the same local address, it is fine to leave the old entries in the cache
even if we have changed addresses. This allows a valid PMKSA cache entry
to be used when restoring the same MAC address for the same ESS.
Signed-off-by: Jouni Malinen <j@w1.fi>
This makes the implementation more readable by sharing the same set of
enum values for all the parameters related to what kind of random MAC
addresses are used.
Signed-off-by: Jouni Malinen <j@w1.fi>
wpa_s->last_mac_addr_change.sec might be zero in the special case of UML
testing with time travel since it would be possible to complete the test
case steps within one second of the system start.
Signed-off-by: Jouni Malinen <j@w1.fi>
When MAC address randomization settings change we should use a new MAC
address even if we are associating to the same ESS.
For example, consider this scenario:
- hardware MAC is being used,
- we disconnect from the network,
- policy/style is changed via D-Bus to turn randomization on,
- we reconnect to the same network.
In the last step a randomized MAC address should be used.
Changes to the randomization settings include both changes to the
policy/style to be used and changes to the pregenerated MAC address
value in case of mac_addr==3.
Signed-off-by: Andrzej Ostruszka <amo@semihalf.com>
Facilitate emitting more station information over D-Bus for use by the
connection manager.
* Add storage for more NL80211_STA_INFO_* fields to data structures, and
move them through the system.
* Reorder NL80211_STA_INFO_* fields in driver_nl80211.c to match the
ordering in nl80211.h.
* Convert signal field to an integer to support holding WPA_INVALID_NOISE
and avoid changing logging.
* Add fields to hostap_sta_driver_data to capture more information
* fcs_error_count
* beacon_loss_count
* expected_throughput
* rx_drop_misc
* rx_mpdus
* rx_hemcs
* tx_hemcs
* rx_he_nss
* tx_he_nss
* avg_signal
* avg_beacon_signal
* avg_ack_signal
* Add struct hostap_sta_driver_data to struct wpa_signal_info and remove
redundant fields and redundant attribute parsing
* Change logging when printing txrate to handle unsigned long
value
Signed-off-by: David Ruth <druth@chromium.org>
Since wpa_supplicant can change MAC address of the interface on its own
(with randomization enabled) it makes sense to introduce MACAddress as a
property of the interface and send notifications about its change.
This allows other applications to just use D-Bus instead of both
communicating over D-Bus with wpa_supplicant and listening to Netlink
notifications for MAC changes.
Signed-off-by: Andrzej Ostruszka <amo@semihalf.com>
There are several cases where memory allocations are not
checked for success. Add conditions and error messages, as some
analyzers complain about that.
Signed-off-by: Micha Hashkes <micha.hashkes@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Even if the use of H2E isn't strictly mandatory when using SAE on 6 GHz,
WPA3-Personal pushes it on 6 GHz, so enable H2E automatically when
connecting to a BSS on the 6 GHz band if it was not enabled in the
configuration.
Signed-off-by: Jimmy Chen <jimmycmchen@google.com>
On NixOS[1] - a Linux distribution which allows to configure a full OS
declaratively - it's possible to configure SSIDs for `wpa_supplicant`
like this:
networking.wireless.networks = {
myssid = {
pskRaw = "<redacted>";
};
};
It's also possible to add networks "imperatively" using `wpa_gui` or
`wpa_cli`. However it's not possible to do both because if the first
option is used, NixOS creates a read-only symlink at
`/etc/wpa_supplicant.conf` and then it's not possible for
`wpa_supplicant` anymore to write to it.
This patch aims to help us changing this: while "declarative" SSID
configuration can be quite useful, it's a bad idea for e.g. sensitive
stuff like a WPA2 enterprise network.
The original idea was to use `-I`[2] for immutable configs (including
"declarative" networks) on NixOS and `-c /etc/wpa_supplicant.conf` for
anything "imperative".
However this doesn't really work out because if a wifi network from a
config file specified with `-I` is changed by e.g. `wpa_gui`, it's
silently overwritten in `/etc/wpa_supplicant.conf` (specified with
`-c`) which is IMHO unintuitive (in our case at least). This patch
basically declares each network defined in a config file passed via `-I`
to `wpa_supplicant` as "read-only" and doesn't write these "read-only"
networks to `/etc/wpa_supplicant.conf`.
A bit more context can be found on GitHub in the PR where I implemented
this[3].
[1] https://nixos.org/
[2] Added in e6304cad47
[3] https://github.com/NixOS/nixpkgs/pull/113716
Signed-off-by: Maximilian Bosch <maximilian@mbosch.me>
Add new 'mac_addr' policy (3) with which supplicant expects to also
obtain 'mac_value' with pregenerated value of MAC address to be used for
given SSID.
The main difference between this policy and policy 1 is the ability to
control persistence of the MAC address used. For example if there is
a requirement to always use the same (but random) MAC address for given
SSID (even if user removes/forgets the network) this could be handled
outside of the wpa_supplicant by using some SSID based hashing scheme to
generate MAC (or by just storing the randomly generated one) and
providing it to wpa_supplicant together with mac_addr=3 policy.
Signed-off-by: Andrzej Ostruszka <amo@semihalf.com>
For WPA2/WPA3 authentication mode, wpa_supplicant needs to notify
CurrentAuthMode property change when wpa_s->key_mgmt changes, so
NetworkManager can judge whether it needs to request a password based on
this.
Call wpas_notify_auth_changed() when starting a new connection item,
i.e., after having updated wpa_s->key_mgmt.
Signed-off-by: xinpeng wang <wangxinpeng@uniontech.com>
OCV cannot be used without PMF and such a configuration were to be used
with wpa_supplicant, the AP would reject the association. hostapd is
already enabling PMF automatically whenever OCV is being enabled, so do
the same with wpa_supplicant.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
If a higher priority BSS has invalid security parameters, e.g., an
invalid SAE password, and a lower priority BSS is discovered only after
the local network profile has been temporarily disabled, the BSSID
ignoring mechanism is not sufficient to allow the lower priority BSS to
be tried and all consecutive attempts will continue to use the higher
priority BSS. This might prevent connection in some unexpected cases
with invalid network configuration.
Extend BSSID ignoring mechanism to work in this type of a case by
ignoring the BSSID that resulted in disabling the SSID temporarily
during the first connection attempt after having re-enabled the SSID.
This allows a lower priority BSS, if any is available in scan results,
to be tried next to see if it might have working security parameters.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
wpa_supplicant has support for only a single FT key hierarchy and as
such, cannot use more than a single mobility domain at a time. Do not
allow FT protocol to be started if there is a request to reassociate to
a different BSS within the same ESS if that BSS is in a different
mobility domain. This results in the initial mobility domain association
being used whenever moving to another mobility domain.
While it would be possible to add support for multiple FT key hierachies
and multiple mobility domains in theory, there does not yet seem to be
sufficient justification to add the complexity needed for that due to
limited, if any, deployment of such networks. As such, it is simplest to
just prevent these attempts for now and start with a clean initial
mobility domain association.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
During cross SSID roaming wpa_supplicant ended up using the default
RSNE/RSNXE in EAPOL-Key msg 2/4 though the driver indicated
(Re)Association Request frame elements without RSNE/RSNXE. This causes
RSNE/RSNXE mismatch between (Re)Association Request frame and EAPOL-Key
msg 2/4.
To avoid this skip copying the default RSNE/RSNXE if the driver
indicates the actually used (Re)Association Request frame elements in
the association event.
Signed-off-by: Utkarsh Soni <quic_usoni@quicinc.com>
