The internal WMM AC parameters use just the exponent of the CW value,
while nl80211 reports the full CW value. This led to completely bogus
CWmin/CWmax values in the WMM IE when a regulatory limit was present.
Fix this by converting the value to the exponent before passing it on.
Fixes: 636c02c6e9 ("nl80211: Add regulatory wmm_limit to hostapd_channel_data")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
nl80211 uses a different queue mapping from hostap, so AC indexes need
to be converted.
Fixes: 636c02c6e9 ("nl80211: Add regulatory wmm_limit to hostapd_channel_data")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Local variable should be used. This fixes an issue where IEs are
available only from a Beacon frame.
Fixes: ad06ac0b0 ("Move throughput estimation into a helper function")
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
The size of a single route(4) message cannot be derived from
either the size of the AF_INET or AF_INET6 routing tables.
Both could be empty or very large.
As such revert back to a buffer size of 2048 which mirrors
other programs which parse the routing socket.
Signed-off-by: Roy Marples <roy@marples.name>
Now that both hostapd and wpa_supplicant react to interface flag
changes, there is no need to set or remove IFF_UP.
It should be an administrative flag only.
Signed-off-by: Roy Marples <roy@marples.name>
There is little point in having both and it brings interface
addition/removal and IFF_UP notifications to hostapd.
Signed-off-by: Roy Marples <roy@marples.name>
When external authentication is used, the station send mlme frame (auth)
to the driver may not be able to get the frequency (bss->freq) after
hostap.git commit b6f8b5a9 ("nl80211: Update freq only when CSA
completes"). Use the assoc_freq to send the MLME frame when SAE external
authentication is used to avoid this issue.
Signed-off-by: Ouden <Ouden.Biz@gmail.com>
This commit introduces additional stats to query through
QCA_NL80211_VENDOR_SUBCMD_UPDATE_STA_INFO.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This adds support for generating an encrypted backup of the local
Configurator information for the purpose of enrolling a new
Configurator. This includes all ASN.1 construction and data encryption,
but the configuration and connector template values in
dpp_build_conf_params() are not yet complete.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Process the received DPPEnvelopedData when going through Configurator
provisioning as the Enrollee (the new Configurator). This parses the
message, derives the needed keys, and decrypts the Configurator
parameters. This commit stores the received information in
auth->conf_key_pkg, but the actually use of that information to create a
new Configurator instance will be handled in a separate commit.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
There is no need for the Protocol Version attribute in Authentication
Response if the peer is a DPP R1 device since such device would not know
how to use this attribute. To reduce risk for interoperability issues,
add this new attribute only if the peer included it in Authentication
Request.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add an attribute QCA_WLAN_VENDOR_ATTR_RTPLINST_PRIMARY_FREQUENCY for
primary channel center frequency in the definition for Representative
Tx Power List (RTPL) list entry instance. This is required for 6 GHz
support, since the 6 GHz channel numbers overlap with existing 2.4 GHz
and 5 GHz channel numbers thus requiring frequency values to uniquely
identify channels.
Mark QCA_WLAN_VENDOR_ATTR_RTPLINST_PRIMARY as deprecated if both the
driver and user space application support 6 GHz. For backward
compatibility, QCA_WLAN_VENDOR_ATTR_RTPLINST_PRIMARY is still used if
either the driver or user space application or both do not support the
6 GHz band.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The recent addition of the X.509v3 certificatePolicies parser had a
copy-paste issue on the inner SEQUENCE parser that ended up using
incorrect length for the remaining buffer. Fix that to calculate the
remaining length properly to avoid reading beyond the end of the buffer
in case of corrupted input data.
Credit to OSS-Fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20363
Fixes: d165b32f38 ("TLS: TOD-STRICT and TOD-TOFU certificate policies")
Signed-off-by: Jouni Malinen <j@w1.fi>
This Python script is an example on how nfcpy can be used to drive an
NFC Device to perform DPP bootstrapping operations over DPP (tag with
NFC URI and negotiated connection handover).
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Make the selected channel available for upper layer software to use,
e.g., when starting DPP listen operation during NFC negotiated
connection handover.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add new control interface commands "DPP_NFC_HANDOVER_REQ own=<id>
uri=<URI>" and "DPP_NFC_HANDOVER_SEL own=<id> uri=<URI>" to support NFC
negotiated connection handover. These commands are used to report a DPP
URI received from a peer NFC Device in Handover Request and Handover
Select messages. The commands return peer bootstrapping information ID
or FAIL on failure. The returned ID is used similarly to any other
bootstrapping information to initiate DPP authentication.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The new dpp_gen_uri() helper function can be used to build the
bootstrapping URI from locally stored information. This can be used to
make it easier to update the URI, e.g., for NFC negotiated connection
handover cases.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This increases the limit of how many data fragments can be supported
with the internal HMAC implementation. The previous limit was hit with
some FT use cases.
Signed-off-by: Jouni Malinen <j@w1.fi>
"finally" handler should not trigger a new exception when trying to
clear state for non-DPP builds. In addition, couple of checks for DPP
capability in the build were missing.
Signed-off-by: Jouni Malinen <j@w1.fi>
Use a helper function for this and add checks for number of test cases
that were missing this. This gets rid of undesired FAIL results
(converts them to SKIP) for test runs where the station do not support
SAE.
Signed-off-by: Jouni Malinen <j@w1.fi>
This commit introduces the vendor event
QCA_NL80211_VENDOR_SUBCMD_REQUEST_SAR_LIMITS_EVENT.
Host drivers can request user space application to set SAR power
limits with this event.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add a new QCA vendor attribute to set thermal level to the driver from
userspace. The driver/firmware takes actions requested by userspace to
mitigate high temperature such as throttling TX etc. The driver may
choose the level of throttling and other actions for various thermal
levels set by userspace.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Initial OWE implementation used SHA256 when deriving the PTK for all OWE
groups. This was supposed to change to SHA384 for group 20 and SHA512
for group 21. The new owe_ptk_workaround=1 network parameter can be used
to enable older behavior mainly for testing purposes. There is no impact
to group 19 behavior, but if enabled, this will make group 20 and 21
cases use SHA256-based PTK derivation which will not work with the
updated OWE implementation on the AP side.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Initial OWE implementation used SHA256 when deriving the PTK for all OWE
groups. This was supposed to change to SHA384 for group 20 and SHA512
for group 21. The new owe_ptk_workaround parameter can be used to enable
workaround for interoperability with stations that use SHA256 with
groups 20 and 21. By default, only the appropriate hash function is
accepted. When workaround is enabled (owe_ptk_workaround=1), the
appropriate hash function is tried first and if that fails, SHA256-based
PTK derivation is attempted. This workaround can result in reduced
security for groups 20 and 21, but is required for interoperability with
older implementations. There is no impact to group 19 behavior.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Previous implementation was hardcoding use of SHA256 PMK-to-PTK
derivation for all groups. Replace that with hash algorithm selection
based on the length of the prime similarly to the way this was done for
other derivation steps in OWE.
This breaks backwards compatibility when using group 20 or 21; group 19
behavior remains same.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
