From j at w1.fi  Sat Mar  1 11:04:34 2025
From: j at w1.fi (Jouni Malinen)
Date: Sat, 1 Mar 2025 21:04:34 +0200
Subject: Disable FIPS mode when RADIUS is being used
In-Reply-To: <E73D97EB-4345-4EE3-AC45-358601FC3145@deployingradius.com>
References: <E73D97EB-4345-4EE3-AC45-358601FC3145@deployingradius.com>
Message-ID: <Z8NaQoQETSBETvx2@w1.fi>

On Mon, Feb 24, 2025 at 04:45:10PM -0500, Alan DeKok wrote:
>   OpenSSL can operate in FIPS mode, where this is a configuration flag, and not a build requirement.  Applications like RADIUS need to disable FIPS, otherwise the Response Authenticator and Message-Authenticator won't be calculated correctly.

What is the purpose for forcing FIPS mode to be used by default in
systemwide configuration? If that is to prevent use of deprecated crypto
algorithms and parameters, it feels wrong to disable that. If that is
for some other reason, it would be good to understand what that other
reason is. I could understand doing this in some cases where the Linux
kernel command line parameter fips=1 is used to force certain crypto
operation validation to be performed without any intent to actually
certify the system as being compliant with FIPS requirements.

>   OpenSSL will not return an error when asked to do MD4 / MD5 calculations.  It will just silently do the wrong thing.  For an example FreeRADIUS / eapol_test output, see:

I'm not sure what that claim is based on.. OpenSSL (well, at least 3.4)
reports that the algorithm cannot be fetched. There were number of cases
where hostap.git code did not pass that to upper layers, including many
RADIUS cases, and I fixed those, but in any case, it is quite clear that
the MD4/MD5 operation itself is failing. And with the current hostap.git
snapshot, it is now quite obvious in eapol_test output as well (and its
behavior: it won't send the Authentication-Request message anymore if it
fails to generate the authenticator).

>   I've attached two patches.
> 
>   One patch adds a fips_disable() function to src/crypto/crypto*.c.  The OpenSSL one tries to disable FIPS, and returns an error if it cannot.  The other crypto*.c files have an empty function defined, which always succeeds.

I would prefer to hide this all in OpenSSL specific code in
crypto_openssl.c and not make it more complex for other libraries.

>  The second patch makes the RADIUS client and server call the new fips_disable() function.

Or upper layer code.. RADIUS code should not need to know about such
detail in one of the possible crypto libraries.

I pushed out different way of addressing this internally within
crypto_openssl.c. This is done only in builds that do not include
CONFIG_FIPS=y.

It should also be noted that FIPS mode in OpenSSL is not the only issue.
It is also possible to use openssl.cnf to make applications load only
the fips provider by default. That will break lots of functionality
needed for Wi-Fi, i.e., this is not limited to MD4/MD5. This will also
break cases like use of HMAC-SHA256 with a short salt instead of a key
(i.e., cases that show up in many protocols, including TLS which is
considered an exception within OpenSSL itself but not for external
users). That HMAC-SHA256 case is needed for SAE (WPA3-Personal), i.e.,
this type of OpenSSL configuration is completely unusable for almost all
Wi-Fi use cases..

The changes I added for this will handle both disabling of FIPS mode and
explicit loading of the default provider if the fips provider is loaded.
I added this only for OpenSSL 3.x and newer since the older versions are
not really supported (well, at least freely) anymore.

-- 
Jouni Malinen                                            PGP id EFC895FA


From aland at deployingradius.com  Sat Mar  1 12:18:26 2025
From: aland at deployingradius.com (Alan DeKok)
Date: Sat, 1 Mar 2025 15:18:26 -0500
Subject: Disable FIPS mode when RADIUS is being used
In-Reply-To: <Z8NaQoQETSBETvx2@w1.fi>
References: <E73D97EB-4345-4EE3-AC45-358601FC3145@deployingradius.com>
 <Z8NaQoQETSBETvx2@w1.fi>
Message-ID: <745EBBD7-F2D5-4642-8E89-39ABDB7EB69A@deployingradius.com>

On Mar 1, 2025, at 2:04?PM, Jouni Malinen <j at w1.fi> wrote:
> What is the purpose for forcing FIPS mode to be used by default in
> systemwide configuration?

  The patch was simple.  The second patch I sent was a lot less intrusive.

> I'm not sure what that claim is based on.. OpenSSL (well, at least 3.4)
> reports that the algorithm cannot be fetched. There were number of cases
> where hostap.git code did not pass that to upper layers, including many
> RADIUS cases, and I fixed those,

  Thanks, that is the better fix.  My tests were superficial, and I just wanted to highlight the problem and a potential solution.

> I pushed out different way of addressing this internally within
> crypto_openssl.c. This is done only in builds that do not include
> CONFIG_FIPS=y.

  Thanks.

> The changes I added for this will handle both disabling of FIPS mode and
> explicit loading of the default provider if the fips provider is loaded.
> I added this only for OpenSSL 3.x and newer since the older versions are
> not really supported (well, at least freely) anymore.

  That makes sense.

  Alan DeKok.



From jaak at ristioja.ee  Sat Mar  1 11:30:34 2025
From: jaak at ristioja.ee (Jaak Ristioja)
Date: Sat, 1 Mar 2025 21:30:34 +0200
Subject: Incorrect deletion of PID file, duplicate background processes?
Message-ID: <815a631c-edd2-498e-b6a5-741b70935b65@ristioja.ee>

Hi,

It appears that wpa_priv deletes the PID file of an existing background 
process. This may lead to multiple wpa_priv background processes being 
spawned:

# grep -H ^ /run/wpa_priv.pid; wpa_priv -B -P /run/wpa_priv.pid 
nl80211:wlan0; grep -H ^ /run/wpa_priv.pid; pgrep wpa_priv
grep: /run/wpa_priv.pid: No such file or directory
/run/wpa_priv.pid:24534
24534
# grep -H ^ /run/wpa_priv.pid; wpa_priv -B -P /run/wpa_priv.pid 
nl80211:wlan0; grep -H ^ /run/wpa_priv.pid; pgrep wpa_priv
/run/wpa_priv.pid:24534
Socket exists and seems to be in use - cannot override it
Delete '/var/run/wpa_priv/wlan0' manually if it is not used anymore
grep: /run/wpa_priv.pid: No such file or directory
24534
# grep -H ^ /run/wpa_priv.pid; wpa_priv -B -P /run/wpa_priv.pid 
nl80211:wlan0; grep -H ^ /run/wpa_priv.pid; pgrep wpa_priv
grep: /run/wpa_priv.pid: No such file or directory
/run/wpa_priv.pid:24543
24534
24543

After a quick look at the source code, it seems that wpa_supplicant and 
possibly other programs may be also have similar behavior.


Best regards,
Jaak Ristioja


From j at w1.fi  Sun Mar  2 09:35:15 2025
From: j at w1.fi (Jouni Malinen)
Date: Sun, 2 Mar 2025 19:35:15 +0200
Subject: Log RADIUS accounting data
In-Reply-To: <19534f5cea5.b09e79d8227781.1833931118950472593@davidbenko.dev>
References: <19534f5cea5.b09e79d8227781.1833931118950472593@davidbenko.dev>
Message-ID: <Z8SW0__gIFvoORk1@w1.fi>

On Sun, Feb 23, 2025 at 11:37:59PM +0100, D?vid Benko wrote:
> There is a long standing (over a decade) TODO on processing RADIUS server
> accounting requests:
> https://w1.fi/cgit/hostap/tree/src/radius/radius_server.c?id=012a893c469157d5734f6f33953497ea6e3b0169#n1677
> 
> I created a pair of patches implementing a new callback interface for
> accounting requests (patch 1) and the callback which simply logs all received
> messages (patch 2). Configuration option to turn it on or off is also included.
> 
> Even though the TODO mentions writing accounting information to a file or
> database, I think logging is well sufficient for many of hostapd's use cases
> and definitely better than nothing.

Thanks, applied.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Sun Mar  2 09:35:53 2025
From: j at w1.fi (Jouni Malinen)
Date: Sun, 2 Mar 2025 19:35:53 +0200
Subject: [PATCH] MACsec: Add option to always include ICV Indicator
In-Reply-To: <e9feb9ec963044c4b705c752544f7dc7@elvac.eu>
References: <e9feb9ec963044c4b705c752544f7dc7@elvac.eu>
Message-ID: <Z8SW-ZQzQOU6q0LM@w1.fi>

On Tue, Feb 25, 2025 at 08:18:06AM +0000, Mart?nek Petr wrote:
> [PATCH] MACsec: Add option to always include ICV Indicator
> 
> Some older MACsec switches incorrectly require ICV Indicator to be present even
> when ICV has default length (CISCO C3560CX). To allow communication with such
> devices option include-icv-indicator was added to always include ICV Indicator.
> 
> Similar option is found in configuration of some other switches:
> Cisco:
> include-icv-indicator - this parameter configures inclusion of the optional ICV
> Indicator as part of the transmitted MACsec Key Agreement PDU (MKPDU). This
> configuration is necessary for MACsec to interoperate with routers that run
> software prior to IOS XR version 6.1.3. This configuration is also important
> in a service provider WAN setup where MACsec interoperates with other vendor
> MACsec implementations that expect ICV indicator to be present in the MKPDU.
> 
> fortiswitch:
> include-mka-icv-ind: The MACsec Key Agreement (MKA) integrity check value (ICV)
> indicator is always included. (enabled by default)

Thanks, applied.

-- 
Jouni Malinen                                            PGP id EFC895FA


From nchernikov at maxlinear.com  Mon Mar  3 07:19:37 2025
From: nchernikov at maxlinear.com (Nikita Chernikov)
Date: Mon, 3 Mar 2025 15:19:37 +0000
Subject: [PATCH] wpa_auth: Reconfigure group rekey timer upon wpa_reconfig
Message-ID: <CY8PR19MB7252D35DCF5B38A4697E166BDBC92@CY8PR19MB7252.namprd19.prod.outlook.com>

From 98487e906944c456f2a784d43f47125fd9796f85 Mon Sep 17 00:00:00 2001
From: Nikita Chernikov <nchernikov at maxlinear.com>
Date: Fri, 14 Feb 2025 18:04:28 +0530
Subject: [PATCH] wpa_auth: Reconfigure group rekey timer upon wpa_reconfig
To: hostap at lists.infradead.org

During BSS reload (ctrl iface or SIGHUP) need to reconfigure the
group rekey timer, as it might change for specific BSS via the new config file.
If not reconfigured, the previous running timer will need to expire in order to apply
the new group rekey timeout.

Signed-off-by: Nikita Chernikov <nchernikov at maxlinear.com>
---
 src/ap/wpa_auth.c    | 14 ++++++++++++++
 1 files changed, 14 insertions(+)

diff --git a/src/ap/wpa_auth.c b/src/ap/wpa_auth.c
index ffb88a03f..671eacd2c 100644
--- a/src/ap/wpa_auth.c
+++ b/src/ap/wpa_auth.c
@@ -652,6 +652,18 @@ static void wpa_auth_pmksa_free_cb(struct rsn_pmksa_cache_entry *entry,
 ?????wpa_auth_for_each_sta(wpa_auth, wpa_auth_pmksa_clear_cb, entry);
 }
 
+static void wpa_reconfig_group_rekey_timer(struct wpa_authenticator *wpa_auth)
+{
+?????if (!wpa_auth)
+???????????return;
+
+?????eloop_cancel_timeout(wpa_rekey_ptk, wpa_auth, NULL);
+
+?????if (wpa_auth->conf.wpa_group_rekey) {
+???????????eloop_register_timeout(wpa_auth->conf.wpa_group_rekey,
+???????????????????????       0, wpa_rekey_gtk, wpa_auth, NULL);
+?????}
+}
 
 static int wpa_group_init_gmk_and_counter(struct wpa_authenticator *wpa_auth,
 ?????????????????????????????  struct wpa_group *group)
@@ -990,6 +1002,8 @@ int wpa_reconfig(struct wpa_authenticator *wpa_auth,
 ?????group->GInit = false;
 ?????wpa_group_sm_step(wpa_auth, group);
 
+?????wpa_reconfig_group_rekey_timer(wpa_auth);
+
 ?????return 0;
 }
 
--
2.17.1

From juliusz at wolfssl.com  Tue Mar  4 04:29:32 2025
From: juliusz at wolfssl.com (Juliusz Sosinowicz)
Date: Tue,  4 Mar 2025 13:29:32 +0100
Subject: [PATCH] run_ap_wpa2_eap_tls_intermediate_ca_ocsp[_revoked]: fix cert config for wolfSSL
Message-ID: <20250304122932.1169952-1-juliusz@wolfssl.com>

When wolfSSL is on the server side, it won't send the entire chain. The client needs to have the server CA loaded to be able to verify the server and needs to load user_and_ica.pem so it sends a cert chain.

Use entire cert chain PEM since the test relies on chain being sent. wolfSSL only sends the certificate that was loaded and not the full chain.

Signed-off-by: Juliusz Sosinowicz <juliusz at wolfssl.com>
---
 .../iCA-server/ica_and_server-revoked.pem     | 167 ++++++++++++++++++
 .../auth_serv/iCA-server/ica_and_server.pem   | 167 ++++++++++++++++++
 tests/hwsim/auth_serv/ica-generate.sh         |   2 +
 tests/hwsim/test_ap_eap.py                    |  16 +-
 4 files changed, 350 insertions(+), 2 deletions(-)
 create mode 100644 tests/hwsim/auth_serv/iCA-server/ica_and_server-revoked.pem
 create mode 100644 tests/hwsim/auth_serv/iCA-server/ica_and_server.pem

diff --git a/tests/hwsim/auth_serv/iCA-server/ica_and_server-revoked.pem b/tests/hwsim/auth_serv/iCA-server/ica_and_server-revoked.pem
new file mode 100644
index 0000000000..22997b8655
--- /dev/null
+++ b/tests/hwsim/auth_serv/iCA-server/ica_and_server-revoked.pem
@@ -0,0 +1,167 @@
+Certificate:
+    Data:
+        Version: 3 (0x2)
+        Serial Number:
+            5c:9d:e4:a6:d1:7a:49:c8:83:75:e7:57:68:f7:72:16:b2:ae:b7:83
+        Signature Algorithm: sha256WithRSAEncryption
+        Issuer: C=FI, O=w1.fi, CN=Server Intermediate CA
+        Validity
+            Not Before: May  3 15:20:10 2020 GMT
+            Not After : May  1 15:20:10 2030 GMT
+        Subject: C=FI, O=w1.fi, CN=server-revoked.w1.fi
+        Subject Public Key Info:
+            Public Key Algorithm: rsaEncryption
+                RSA Public-Key: (2048 bit)
+                Modulus:
+                    00:ba:86:db:62:ad:55:bc:3b:41:f1:c1:ef:3d:61:
+                    13:6d:65:8a:d1:be:58:41:a6:e0:5d:f2:c5:f3:a7:
+                    c1:c2:6c:9e:b0:5f:f0:16:2c:e4:ba:7d:26:b7:69:
+                    43:72:b1:d7:28:d2:06:3d:6e:9c:67:32:38:3f:3c:
+                    63:94:8d:63:e9:7f:b3:7b:67:0b:d6:c9:02:ec:da:
+                    7e:e1:5b:21:e4:a1:ea:01:ec:b8:bd:6f:5e:d2:92:
+                    e5:33:da:a5:13:a6:8e:04:b5:19:7a:07:9a:e8:03:
+                    ee:bd:4a:2c:65:6c:ec:3a:48:38:7e:0d:30:30:ee:
+                    1a:d9:1a:be:02:d0:e1:f2:95:17:21:08:3c:49:4d:
+                    8f:11:c7:b4:8c:e6:93:4b:4a:fa:dd:ac:0a:72:d8:
+                    82:8a:e1:6c:99:1e:77:1b:88:12:b3:72:cf:dc:fa:
+                    57:d2:63:e1:2d:c0:5a:57:36:d4:ff:37:20:20:01:
+                    b4:11:19:2c:f9:9b:f6:fa:93:ff:ca:69:f2:84:eb:
+                    6f:af:44:b8:18:e3:d8:42:29:97:21:01:e1:47:a1:
+                    fc:ed:58:74:b0:ab:f9:75:5c:e8:49:aa:16:4a:19:
+                    31:e8:c5:8c:60:99:48:9f:d9:78:92:ec:31:0b:20:
+                    64:d9:57:1c:6e:6a:a6:dd:f8:55:2f:cc:2b:76:11:
+                    b5:9b
+                Exponent: 65537 (0x10001)
+        X509v3 extensions:
+            X509v3 Basic Constraints: critical
+                CA:FALSE
+            X509v3 Subject Key Identifier: 
+                FB:67:34:A4:0E:E6:BB:BF:90:0D:7C:B2:69:E8:04:D5:71:8F:76:44
+            X509v3 Authority Key Identifier: 
+                keyid:EB:DC:8D:38:75:10:2F:E6:82:8E:FE:43:EC:9F:7E:63:22:BD:51:55
+
+            X509v3 Subject Alternative Name: critical
+                DNS:server-revoked.w1.fi
+            X509v3 Extended Key Usage: critical
+                TLS Web Server Authentication
+            X509v3 Key Usage: 
+                Digital Signature, Key Encipherment
+    Signature Algorithm: sha256WithRSAEncryption
+         22:c0:a0:7c:25:b4:4d:61:44:25:09:9c:14:8d:35:6e:36:7b:
+         91:60:6b:35:90:48:a9:a2:ee:81:70:c4:d8:2a:9d:a3:7e:a2:
+         c9:0c:dc:b2:73:98:01:cf:db:d4:3a:17:8a:b6:3d:b5:97:47:
+         33:e9:b6:14:ed:a6:8e:a4:6d:34:d0:03:3a:01:04:ce:28:24:
+         f9:c3:15:a9:b1:8c:2a:dc:8d:40:98:ac:78:8f:f5:fc:53:88:
+         0e:84:28:39:86:75:59:ad:12:54:77:f2:9c:e1:d2:4e:e1:ee:
+         8d:57:f3:41:ab:15:4d:ab:77:75:47:9a:c6:36:28:08:b5:8d:
+         c7:9f:5a:87:87:f8:a7:17:9a:44:4e:ce:84:24:12:da:7f:a8:
+         ab:15:fd:24:9b:cf:1c:ae:2f:8f:13:28:27:09:1e:57:2b:ca:
+         1f:c8:bc:a4:95:08:27:4e:c4:21:68:a5:45:9f:5a:42:1c:7f:
+         37:59:d7:ed:30:be:ed:26:12:5d:80:f5:7d:7d:94:ff:52:56:
+         fc:67:0f:3f:00:21:e7:b4:2f:48:7b:77:86:fb:16:28:ab:68:
+         e1:4d:80:eb:5e:4b:99:88:2f:ec:a3:1d:06:c5:04:2e:bb:56:
+         fb:6b:75:9d:5b:78:83:63:2b:70:7c:21:94:a1:58:a4:8e:8b:
+         30:d3:28:88
+-----BEGIN CERTIFICATE-----
+MIIDozCCAougAwIBAgIUXJ3kptF6SciDdedXaPdyFrKut4MwDQYJKoZIhvcNAQEL
+BQAwPjELMAkGA1UEBhMCRkkxDjAMBgNVBAoMBXcxLmZpMR8wHQYDVQQDDBZTZXJ2
+ZXIgSW50ZXJtZWRpYXRlIENBMB4XDTIwMDUwMzE1MjAxMFoXDTMwMDUwMTE1MjAx
+MFowPDELMAkGA1UEBhMCRkkxDjAMBgNVBAoMBXcxLmZpMR0wGwYDVQQDDBRzZXJ2
+ZXItcmV2b2tlZC53MS5maTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
+ALqG22KtVbw7QfHB7z1hE21litG+WEGm4F3yxfOnwcJsnrBf8BYs5Lp9JrdpQ3Kx
+1yjSBj1unGcyOD88Y5SNY+l/s3tnC9bJAuzafuFbIeSh6gHsuL1vXtKS5TPapROm
+jgS1GXoHmugD7r1KLGVs7DpIOH4NMDDuGtkavgLQ4fKVFyEIPElNjxHHtIzmk0tK
++t2sCnLYgorhbJkedxuIErNyz9z6V9Jj4S3AWlc21P83ICABtBEZLPmb9vqT/8pp
+8oTrb69EuBjj2EIplyEB4Ueh/O1YdLCr+XVc6EmqFkoZMejFjGCZSJ/ZeJLsMQsg
+ZNlXHG5qpt34VS/MK3YRtZsCAwEAAaOBmjCBlzAMBgNVHRMBAf8EAjAAMB0GA1Ud
+DgQWBBT7ZzSkDua7v5ANfLJp6ATVcY92RDAfBgNVHSMEGDAWgBTr3I04dRAv5oKO
+/kPsn35jIr1RVTAiBgNVHREBAf8EGDAWghRzZXJ2ZXItcmV2b2tlZC53MS5maTAW
+BgNVHSUBAf8EDDAKBggrBgEFBQcDATALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQEL
+BQADggEBACLAoHwltE1hRCUJnBSNNW42e5FgazWQSKmi7oFwxNgqnaN+oskM3LJz
+mAHP29Q6F4q2PbWXRzPpthTtpo6kbTTQAzoBBM4oJPnDFamxjCrcjUCYrHiP9fxT
+iA6EKDmGdVmtElR38pzh0k7h7o1X80GrFU2rd3VHmsY2KAi1jcefWoeH+KcXmkRO
+zoQkEtp/qKsV/SSbzxyuL48TKCcJHlcryh/IvKSVCCdOxCFopUWfWkIcfzdZ1+0w
+vu0mEl2A9X19lP9SVvxnDz8AIee0L0h7d4b7FiiraOFNgOteS5mIL+yjHQbFBC67
+VvtrdZ1beINjK3B8IZShWKSOizDTKIg=
+-----END CERTIFICATE-----
+Certificate:
+    Data:
+        Version: 3 (0x2)
+        Serial Number:
+            d8:d3:e3:a6:cb:e3:cc:f7
+        Signature Algorithm: sha256WithRSAEncryption
+        Issuer: C=FI, L=Tuusula, O=w1.fi, CN=Root CA
+        Validity
+            Not Before: May  3 15:20:10 2020 GMT
+            Not After : May  3 15:20:10 2030 GMT
+        Subject: C=FI, O=w1.fi, CN=Server Intermediate CA
+        Subject Public Key Info:
+            Public Key Algorithm: rsaEncryption
+                RSA Public-Key: (2048 bit)
+                Modulus:
+                    00:a2:b0:de:7f:e6:17:69:4b:bb:8d:dc:4f:8b:95:
+                    33:5e:13:ee:a1:01:f5:82:de:6e:fc:83:db:e7:22:
+                    5f:b9:8d:2b:de:10:72:4e:da:81:c1:f7:f3:eb:0e:
+                    db:5b:5f:90:92:bb:41:68:55:4f:84:d9:73:5b:0c:
+                    6d:40:e6:c5:0f:5d:5c:5e:80:1e:64:87:5a:99:44:
+                    8b:3d:61:20:f0:15:cc:87:95:5b:a0:46:0f:bc:5c:
+                    14:ee:ac:4f:c8:7c:d2:c0:ef:60:94:22:b6:74:05:
+                    4f:ca:97:01:0a:30:b4:50:44:89:d0:c2:6b:e5:7f:
+                    ce:66:22:1a:d6:38:7c:ff:42:42:ca:58:a0:38:85:
+                    ca:f1:b1:1f:33:27:db:bf:5c:49:96:36:7a:11:2f:
+                    62:d7:eb:7e:9f:9b:9c:0e:2b:df:cd:59:bc:ee:e8:
+                    6a:e3:7d:fa:06:ba:34:42:b5:7d:e7:be:e1:7b:85:
+                    af:1b:25:a9:45:33:06:cb:cc:0d:ca:78:5c:56:52:
+                    ac:43:7e:f6:0c:e7:fb:86:b4:ac:d7:f4:b2:54:ee:
+                    65:7a:5c:32:6b:33:a0:68:1b:d8:ea:c8:74:94:08:
+                    00:7f:9b:f0:da:80:0f:f2:45:13:11:63:4c:e6:d2:
+                    97:d3:ae:12:b0:7c:e8:f0:56:c0:7b:7c:82:99:6d:
+                    3b:5d
+                Exponent: 65537 (0x10001)
+        X509v3 extensions:
+            X509v3 Subject Key Identifier: 
+                EB:DC:8D:38:75:10:2F:E6:82:8E:FE:43:EC:9F:7E:63:22:BD:51:55
+            X509v3 Authority Key Identifier: 
+                keyid:A4:FD:B9:39:1B:81:B3:AA:EB:88:1D:D4:81:A9:B5:11:70:CC:A7:E1
+
+            X509v3 Basic Constraints: critical
+                CA:TRUE, pathlen:0
+            X509v3 Key Usage: critical
+                Certificate Sign, CRL Sign
+    Signature Algorithm: sha256WithRSAEncryption
+         86:74:75:b2:bb:b0:85:25:48:38:e1:34:54:d5:d4:3a:9f:0e:
+         b1:96:fd:cc:ea:15:21:72:da:9e:ef:e2:fa:ae:29:74:dc:83:
+         36:87:88:7d:75:51:9a:c5:6e:a8:80:77:3f:5c:ed:9e:ac:57:
+         17:ed:ab:64:4f:15:8b:47:90:0a:17:2a:7e:49:a9:01:a1:41:
+         66:d4:fe:be:18:70:d6:23:f7:0b:0a:53:d7:75:a8:7f:0a:52:
+         1c:1d:8c:63:6f:82:ed:ed:fd:e2:fe:86:ef:0a:4c:f8:d7:93:
+         56:9a:a3:dd:74:02:8c:b3:31:83:c1:8a:66:c6:c0:1d:dc:00:
+         5c:57:f4:31:31:8b:d4:84:d8:da:6d:d6:f6:e4:10:7e:bb:f2:
+         41:95:dd:a6:0c:37:c7:22:80:e6:36:3e:34:c6:1c:73:ab:42:
+         90:6e:f8:db:e8:b6:c0:b2:f5:17:d2:6f:d3:8c:fb:14:25:8e:
+         72:81:45:76:86:f7:d1:d9:3d:ff:b1:a2:10:6f:c0:24:e7:70:
+         3f:2d:cf:32:ee:06:70:d5:1b:04:84:6d:48:69:26:1e:98:5a:
+         ed:e3:61:f5:29:45:88:25:cf:7f:c4:fb:f3:87:a7:11:95:9e:
+         cf:a8:aa:88:db:12:32:66:66:c4:1d:12:b1:62:1d:fa:28:f4:
+         97:ac:df:2e
+-----BEGIN CERTIFICATE-----
+MIIDaDCCAlCgAwIBAgIJANjT46bL48z3MA0GCSqGSIb3DQEBCwUAMEExCzAJBgNV
+BAYTAkZJMRAwDgYDVQQHDAdUdXVzdWxhMQ4wDAYDVQQKDAV3MS5maTEQMA4GA1UE
+AwwHUm9vdCBDQTAeFw0yMDA1MDMxNTIwMTBaFw0zMDA1MDMxNTIwMTBaMD4xCzAJ
+BgNVBAYTAkZJMQ4wDAYDVQQKDAV3MS5maTEfMB0GA1UEAwwWU2VydmVyIEludGVy
+bWVkaWF0ZSBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKKw3n/m
+F2lLu43cT4uVM14T7qEB9YLebvyD2+ciX7mNK94Qck7agcH38+sO21tfkJK7QWhV
+T4TZc1sMbUDmxQ9dXF6AHmSHWplEiz1hIPAVzIeVW6BGD7xcFO6sT8h80sDvYJQi
+tnQFT8qXAQowtFBEidDCa+V/zmYiGtY4fP9CQspYoDiFyvGxHzMn279cSZY2ehEv
+Ytfrfp+bnA4r381ZvO7oauN9+ga6NEK1fee+4XuFrxslqUUzBsvMDcp4XFZSrEN+
+9gzn+4a0rNf0slTuZXpcMmszoGgb2OrIdJQIAH+b8NqAD/JFExFjTObSl9OuErB8
+6PBWwHt8gpltO10CAwEAAaNmMGQwHQYDVR0OBBYEFOvcjTh1EC/mgo7+Q+yffmMi
+vVFVMB8GA1UdIwQYMBaAFKT9uTkbgbOq64gd1IGptRFwzKfhMBIGA1UdEwEB/wQI
+MAYBAf8CAQAwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBCwUAA4IBAQCGdHWy
+u7CFJUg44TRU1dQ6nw6xlv3M6hUhctqe7+L6ril03IM2h4h9dVGaxW6ogHc/XO2e
+rFcX7atkTxWLR5AKFyp+SakBoUFm1P6+GHDWI/cLClPXdah/ClIcHYxjb4Lt7f3i
+/obvCkz415NWmqPddAKMszGDwYpmxsAd3ABcV/QxMYvUhNjabdb25BB+u/JBld2m
+DDfHIoDmNj40xhxzq0KQbvjb6LbAsvUX0m/TjPsUJY5ygUV2hvfR2T3/saIQb8Ak
+53A/Lc8y7gZw1RsEhG1IaSYemFrt42H1KUWIJc9/xPvzh6cRlZ7PqKqI2xIyZmbE
+HRKxYh36KPSXrN8u
+-----END CERTIFICATE-----
diff --git a/tests/hwsim/auth_serv/iCA-server/ica_and_server.pem b/tests/hwsim/auth_serv/iCA-server/ica_and_server.pem
new file mode 100644
index 0000000000..a7545bc056
--- /dev/null
+++ b/tests/hwsim/auth_serv/iCA-server/ica_and_server.pem
@@ -0,0 +1,167 @@
+Certificate:
+    Data:
+        Version: 3 (0x2)
+        Serial Number:
+            5c:9d:e4:a6:d1:7a:49:c8:83:75:e7:57:68:f7:72:16:b2:ae:b7:82
+        Signature Algorithm: sha256WithRSAEncryption
+        Issuer: C=FI, O=w1.fi, CN=Server Intermediate CA
+        Validity
+            Not Before: May  3 15:20:10 2020 GMT
+            Not After : May  1 15:20:10 2030 GMT
+        Subject: C=FI, O=w1.fi, CN=server.w1.fi
+        Subject Public Key Info:
+            Public Key Algorithm: rsaEncryption
+                RSA Public-Key: (2048 bit)
+                Modulus:
+                    00:ac:21:ec:55:e2:94:6c:d5:1b:6d:fa:77:87:7f:
+                    7e:2a:f5:26:4e:3c:28:d4:70:50:70:55:e2:a9:d5:
+                    ab:62:15:01:02:b5:90:e8:55:91:7c:b0:f4:9f:fd:
+                    11:3c:73:72:f7:56:7d:4c:b5:56:21:8f:17:c4:65:
+                    5c:2a:3f:0d:e2:22:a5:80:ed:1a:b0:a8:8c:e2:9a:
+                    f7:8f:77:6d:c5:24:9f:2b:c0:3a:26:9b:13:75:96:
+                    d2:cf:19:4c:ca:ed:90:b3:c8:da:e7:20:03:a6:0a:
+                    5d:ad:04:9d:6b:37:9d:69:e9:6c:63:d5:12:da:ff:
+                    c2:a5:d4:f4:04:df:ce:39:c2:06:3d:3f:ec:8b:3d:
+                    9e:1c:a7:2d:f2:63:53:7e:3a:aa:68:0a:b0:93:b2:
+                    69:3d:23:da:b1:ae:fe:90:fa:c6:ea:ee:35:94:4d:
+                    9a:d8:5d:6f:b9:ed:80:6b:1b:bd:46:56:ab:bf:29:
+                    8a:c9:20:e5:31:3d:11:96:e0:c5:56:58:e1:f1:84:
+                    6d:bc:0f:e5:9b:bc:9f:75:2b:03:01:1a:58:8e:88:
+                    22:b3:0a:7c:8d:b3:4d:1e:82:31:75:7f:cf:28:3a:
+                    aa:c0:f5:c3:45:72:bc:48:f7:9a:61:11:2c:31:d4:
+                    3d:5b:6e:25:ca:2a:ea:88:e9:58:fe:ee:0d:00:d5:
+                    36:8b
+                Exponent: 65537 (0x10001)
+        X509v3 extensions:
+            X509v3 Basic Constraints: critical
+                CA:FALSE
+            X509v3 Subject Key Identifier: 
+                E9:E3:CE:7A:C2:27:BF:88:CF:19:9E:5C:6C:DC:12:C0:D5:00:64:15
+            X509v3 Authority Key Identifier: 
+                keyid:EB:DC:8D:38:75:10:2F:E6:82:8E:FE:43:EC:9F:7E:63:22:BD:51:55
+
+            X509v3 Subject Alternative Name: critical
+                DNS:server.w1.fi
+            X509v3 Extended Key Usage: critical
+                TLS Web Server Authentication
+            X509v3 Key Usage: 
+                Digital Signature, Key Encipherment
+    Signature Algorithm: sha256WithRSAEncryption
+         1b:c4:4a:ea:b3:ee:c3:82:4d:98:93:49:6a:34:98:80:b6:a3:
+         dc:00:d5:ca:27:56:43:e2:71:4c:60:a1:ef:c2:41:9c:fa:93:
+         a4:61:20:f5:3f:2c:3a:91:e8:12:e1:7a:51:c0:86:2b:cf:1b:
+         73:26:b3:0c:e7:03:2e:8e:48:49:3e:32:29:df:b2:9e:d5:29:
+         26:bf:c3:3e:eb:7d:34:96:c7:6e:0e:ae:16:a1:a1:fa:25:dd:
+         a3:2e:3e:4e:3e:76:ff:d6:35:ef:d4:07:2f:d2:6f:48:08:ab:
+         e7:4a:09:ff:43:09:ec:32:49:19:52:cd:30:03:22:3c:f0:9c:
+         9b:e3:fd:bc:e7:f9:d1:7a:da:c6:66:bf:e0:86:95:5c:45:43:
+         07:26:6d:70:fc:24:66:4a:cd:86:bd:6c:d3:7a:0d:12:4b:33:
+         bc:a0:4b:81:08:1a:26:bc:42:a2:e7:37:36:56:ac:ef:85:34:
+         52:89:33:df:b6:33:11:ac:20:67:cd:8d:ce:d7:bb:cb:bc:b5:
+         16:3c:08:cf:c7:1a:68:60:16:9c:55:e6:b5:17:4f:3f:69:f9:
+         b4:18:70:af:60:5d:0f:c4:66:08:b9:75:a3:78:11:f7:8f:8d:
+         f1:2b:4e:05:b9:90:b6:f3:99:8b:0c:43:6a:8c:b4:cc:ff:2f:
+         58:70:d7:8e
+-----BEGIN CERTIFICATE-----
+MIIDkzCCAnugAwIBAgIUXJ3kptF6SciDdedXaPdyFrKut4IwDQYJKoZIhvcNAQEL
+BQAwPjELMAkGA1UEBhMCRkkxDjAMBgNVBAoMBXcxLmZpMR8wHQYDVQQDDBZTZXJ2
+ZXIgSW50ZXJtZWRpYXRlIENBMB4XDTIwMDUwMzE1MjAxMFoXDTMwMDUwMTE1MjAx
+MFowNDELMAkGA1UEBhMCRkkxDjAMBgNVBAoMBXcxLmZpMRUwEwYDVQQDDAxzZXJ2
+ZXIudzEuZmkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsIexV4pRs
+1Rtt+neHf34q9SZOPCjUcFBwVeKp1atiFQECtZDoVZF8sPSf/RE8c3L3Vn1MtVYh
+jxfEZVwqPw3iIqWA7RqwqIzimvePd23FJJ8rwDommxN1ltLPGUzK7ZCzyNrnIAOm
+Cl2tBJ1rN51p6Wxj1RLa/8Kl1PQE3845wgY9P+yLPZ4cpy3yY1N+OqpoCrCTsmk9
+I9qxrv6Q+sbq7jWUTZrYXW+57YBrG71GVqu/KYrJIOUxPRGW4MVWWOHxhG28D+Wb
+vJ91KwMBGliOiCKzCnyNs00egjF1f88oOqrA9cNFcrxI95phESwx1D1bbiXKKuqI
+6Vj+7g0A1TaLAgMBAAGjgZIwgY8wDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQU6ePO
+esInv4jPGZ5cbNwSwNUAZBUwHwYDVR0jBBgwFoAU69yNOHUQL+aCjv5D7J9+YyK9
+UVUwGgYDVR0RAQH/BBAwDoIMc2VydmVyLncxLmZpMBYGA1UdJQEB/wQMMAoGCCsG
+AQUFBwMBMAsGA1UdDwQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAQEAG8RK6rPuw4JN
+mJNJajSYgLaj3ADVyidWQ+JxTGCh78JBnPqTpGEg9T8sOpHoEuF6UcCGK88bcyaz
+DOcDLo5IST4yKd+yntUpJr/DPut9NJbHbg6uFqGh+iXdoy4+Tj52/9Y179QHL9Jv
+SAir50oJ/0MJ7DJJGVLNMAMiPPCcm+P9vOf50Xraxma/4IaVXEVDByZtcPwkZkrN
+hr1s03oNEkszvKBLgQgaJrxCouc3Nlas74U0Uokz37YzEawgZ82Nzte7y7y1FjwI
+z8caaGAWnFXmtRdPP2n5tBhwr2BdD8RmCLl1o3gR94+N8StOBbmQtvOZiwxDaoy0
+zP8vWHDXjg==
+-----END CERTIFICATE-----
+Certificate:
+    Data:
+        Version: 3 (0x2)
+        Serial Number:
+            d8:d3:e3:a6:cb:e3:cc:f7
+        Signature Algorithm: sha256WithRSAEncryption
+        Issuer: C=FI, L=Tuusula, O=w1.fi, CN=Root CA
+        Validity
+            Not Before: May  3 15:20:10 2020 GMT
+            Not After : May  3 15:20:10 2030 GMT
+        Subject: C=FI, O=w1.fi, CN=Server Intermediate CA
+        Subject Public Key Info:
+            Public Key Algorithm: rsaEncryption
+                RSA Public-Key: (2048 bit)
+                Modulus:
+                    00:a2:b0:de:7f:e6:17:69:4b:bb:8d:dc:4f:8b:95:
+                    33:5e:13:ee:a1:01:f5:82:de:6e:fc:83:db:e7:22:
+                    5f:b9:8d:2b:de:10:72:4e:da:81:c1:f7:f3:eb:0e:
+                    db:5b:5f:90:92:bb:41:68:55:4f:84:d9:73:5b:0c:
+                    6d:40:e6:c5:0f:5d:5c:5e:80:1e:64:87:5a:99:44:
+                    8b:3d:61:20:f0:15:cc:87:95:5b:a0:46:0f:bc:5c:
+                    14:ee:ac:4f:c8:7c:d2:c0:ef:60:94:22:b6:74:05:
+                    4f:ca:97:01:0a:30:b4:50:44:89:d0:c2:6b:e5:7f:
+                    ce:66:22:1a:d6:38:7c:ff:42:42:ca:58:a0:38:85:
+                    ca:f1:b1:1f:33:27:db:bf:5c:49:96:36:7a:11:2f:
+                    62:d7:eb:7e:9f:9b:9c:0e:2b:df:cd:59:bc:ee:e8:
+                    6a:e3:7d:fa:06:ba:34:42:b5:7d:e7:be:e1:7b:85:
+                    af:1b:25:a9:45:33:06:cb:cc:0d:ca:78:5c:56:52:
+                    ac:43:7e:f6:0c:e7:fb:86:b4:ac:d7:f4:b2:54:ee:
+                    65:7a:5c:32:6b:33:a0:68:1b:d8:ea:c8:74:94:08:
+                    00:7f:9b:f0:da:80:0f:f2:45:13:11:63:4c:e6:d2:
+                    97:d3:ae:12:b0:7c:e8:f0:56:c0:7b:7c:82:99:6d:
+                    3b:5d
+                Exponent: 65537 (0x10001)
+        X509v3 extensions:
+            X509v3 Subject Key Identifier: 
+                EB:DC:8D:38:75:10:2F:E6:82:8E:FE:43:EC:9F:7E:63:22:BD:51:55
+            X509v3 Authority Key Identifier: 
+                keyid:A4:FD:B9:39:1B:81:B3:AA:EB:88:1D:D4:81:A9:B5:11:70:CC:A7:E1
+
+            X509v3 Basic Constraints: critical
+                CA:TRUE, pathlen:0
+            X509v3 Key Usage: critical
+                Certificate Sign, CRL Sign
+    Signature Algorithm: sha256WithRSAEncryption
+         86:74:75:b2:bb:b0:85:25:48:38:e1:34:54:d5:d4:3a:9f:0e:
+         b1:96:fd:cc:ea:15:21:72:da:9e:ef:e2:fa:ae:29:74:dc:83:
+         36:87:88:7d:75:51:9a:c5:6e:a8:80:77:3f:5c:ed:9e:ac:57:
+         17:ed:ab:64:4f:15:8b:47:90:0a:17:2a:7e:49:a9:01:a1:41:
+         66:d4:fe:be:18:70:d6:23:f7:0b:0a:53:d7:75:a8:7f:0a:52:
+         1c:1d:8c:63:6f:82:ed:ed:fd:e2:fe:86:ef:0a:4c:f8:d7:93:
+         56:9a:a3:dd:74:02:8c:b3:31:83:c1:8a:66:c6:c0:1d:dc:00:
+         5c:57:f4:31:31:8b:d4:84:d8:da:6d:d6:f6:e4:10:7e:bb:f2:
+         41:95:dd:a6:0c:37:c7:22:80:e6:36:3e:34:c6:1c:73:ab:42:
+         90:6e:f8:db:e8:b6:c0:b2:f5:17:d2:6f:d3:8c:fb:14:25:8e:
+         72:81:45:76:86:f7:d1:d9:3d:ff:b1:a2:10:6f:c0:24:e7:70:
+         3f:2d:cf:32:ee:06:70:d5:1b:04:84:6d:48:69:26:1e:98:5a:
+         ed:e3:61:f5:29:45:88:25:cf:7f:c4:fb:f3:87:a7:11:95:9e:
+         cf:a8:aa:88:db:12:32:66:66:c4:1d:12:b1:62:1d:fa:28:f4:
+         97:ac:df:2e
+-----BEGIN CERTIFICATE-----
+MIIDaDCCAlCgAwIBAgIJANjT46bL48z3MA0GCSqGSIb3DQEBCwUAMEExCzAJBgNV
+BAYTAkZJMRAwDgYDVQQHDAdUdXVzdWxhMQ4wDAYDVQQKDAV3MS5maTEQMA4GA1UE
+AwwHUm9vdCBDQTAeFw0yMDA1MDMxNTIwMTBaFw0zMDA1MDMxNTIwMTBaMD4xCzAJ
+BgNVBAYTAkZJMQ4wDAYDVQQKDAV3MS5maTEfMB0GA1UEAwwWU2VydmVyIEludGVy
+bWVkaWF0ZSBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKKw3n/m
+F2lLu43cT4uVM14T7qEB9YLebvyD2+ciX7mNK94Qck7agcH38+sO21tfkJK7QWhV
+T4TZc1sMbUDmxQ9dXF6AHmSHWplEiz1hIPAVzIeVW6BGD7xcFO6sT8h80sDvYJQi
+tnQFT8qXAQowtFBEidDCa+V/zmYiGtY4fP9CQspYoDiFyvGxHzMn279cSZY2ehEv
+Ytfrfp+bnA4r381ZvO7oauN9+ga6NEK1fee+4XuFrxslqUUzBsvMDcp4XFZSrEN+
+9gzn+4a0rNf0slTuZXpcMmszoGgb2OrIdJQIAH+b8NqAD/JFExFjTObSl9OuErB8
+6PBWwHt8gpltO10CAwEAAaNmMGQwHQYDVR0OBBYEFOvcjTh1EC/mgo7+Q+yffmMi
+vVFVMB8GA1UdIwQYMBaAFKT9uTkbgbOq64gd1IGptRFwzKfhMBIGA1UdEwEB/wQI
+MAYBAf8CAQAwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBCwUAA4IBAQCGdHWy
+u7CFJUg44TRU1dQ6nw6xlv3M6hUhctqe7+L6ril03IM2h4h9dVGaxW6ogHc/XO2e
+rFcX7atkTxWLR5AKFyp+SakBoUFm1P6+GHDWI/cLClPXdah/ClIcHYxjb4Lt7f3i
+/obvCkz415NWmqPddAKMszGDwYpmxsAd3ABcV/QxMYvUhNjabdb25BB+u/JBld2m
+DDfHIoDmNj40xhxzq0KQbvjb6LbAsvUX0m/TjPsUJY5ygUV2hvfR2T3/saIQb8Ak
+53A/Lc8y7gZw1RsEhG1IaSYemFrt42H1KUWIJc9/xPvzh6cRlZ7PqKqI2xIyZmbE
+HRKxYh36KPSXrN8u
+-----END CERTIFICATE-----
diff --git a/tests/hwsim/auth_serv/ica-generate.sh b/tests/hwsim/auth_serv/ica-generate.sh
index d3fe7b9645..263c2685a9 100755
--- a/tests/hwsim/auth_serv/ica-generate.sh
+++ b/tests/hwsim/auth_serv/ica-generate.sh
@@ -44,6 +44,7 @@ cat ec-ca-openssl.cnf |
 $OPENSSL req -config openssl.cnf.tmp -batch -new -newkey rsa:2048 -nodes -keyout iCA-server/server.key -out iCA-server/server.req -outform PEM -sha256
 $OPENSSL ca -config openssl.cnf.tmp -batch -keyfile iCA-server/private/cakey.pem -cert iCA-server/cacert.pem -create_serial -in iCA-server/server.req -out iCA-server/server.pem -extensions ext_server -md sha256
 cat iCA-server/cacert.pem iCA-server/server.pem > iCA-server/server_and_ica.pem
+cat iCA-server/server.pem iCA-server/cacert.pem > iCA-server/ica_and_server.pem
 rm openssl.cnf.tmp
 
 echo
@@ -59,6 +60,7 @@ $OPENSSL req -config openssl.cnf.tmp -batch -new -newkey rsa:2048 -nodes -keyout
 $OPENSSL ca -config openssl.cnf.tmp -batch -keyfile iCA-server/private/cakey.pem -cert iCA-server/cacert.pem -create_serial -in iCA-server/server-revoked.req -out iCA-server/server-revoked.pem -extensions ext_server -md sha256
 $OPENSSL ca -config openssl.cnf.tmp -revoke iCA-server/server-revoked.pem -keyfile iCA-server/private/cakey.pem -cert iCA-server/cacert.pem
 cat iCA-server/cacert.pem iCA-server/server-revoked.pem > iCA-server/server-revoked_and_ica.pem
+cat iCA-server/server-revoked.pem iCA-server/cacert.pem > iCA-server/ica_and_server-revoked.pem
 rm openssl.cnf.tmp
 
 echo
diff --git a/tests/hwsim/test_ap_eap.py b/tests/hwsim/test_ap_eap.py
index 3f214a9a9e..8320a56eb7 100644
--- a/tests/hwsim/test_ap_eap.py
+++ b/tests/hwsim/test_ap_eap.py
@@ -4969,7 +4969,13 @@ def test_ap_wpa2_eap_tls_intermediate_ca_ocsp_sha1(dev, apdev, params):
 def run_ap_wpa2_eap_tls_intermediate_ca_ocsp(dev, apdev, params, md):
     params = int_eap_server_params()
     params["ca_cert"] = "auth_serv/iCA-server/ca-and-root.pem"
-    params["server_cert"] = "auth_serv/iCA-server/server.pem"
+    as_hapd = hostapd.Hostapd("as")
+    tls = as_hapd.request("GET tls_library")
+    del as_hapd
+    if "wolfSSL" in tls:
+        params["server_cert"] = "auth_serv/iCA-server/ica_and_server.pem"
+    else:
+        params["server_cert"] = "auth_serv/iCA-server/server.pem"
     params["private_key"] = "auth_serv/iCA-server/server.key"
     fn = ica_ocsp("server.pem", md)
     params["ocsp_stapling_response"] = fn
@@ -5005,7 +5011,13 @@ def run_ap_wpa2_eap_tls_intermediate_ca_ocsp_revoked(dev, apdev, params, md):
     check_ocsp_support(dev[0])
     params = int_eap_server_params()
     params["ca_cert"] = "auth_serv/iCA-server/ca-and-root.pem"
-    params["server_cert"] = "auth_serv/iCA-server/server-revoked.pem"
+    as_hapd = hostapd.Hostapd("as")
+    tls = as_hapd.request("GET tls_library")
+    del as_hapd
+    if "wolfSSL" in tls:
+        params["server_cert"] = "auth_serv/iCA-server/ica_and_server-revoked.pem"
+    else:
+        params["server_cert"] = "auth_serv/iCA-server/server-revoked.pem"
     params["private_key"] = "auth_serv/iCA-server/server-revoked.key"
     fn = ica_ocsp("server-revoked.pem", md)
     params["ocsp_stapling_response"] = fn
-- 
2.43.0



From juliusz at wolfssl.com  Tue Mar  4 05:11:14 2025
From: juliusz at wolfssl.com (Juliusz Sosinowicz)
Date: Tue,  4 Mar 2025 14:11:14 +0100
Subject: [PATCH] wolfssl: Implement EAP-FAST
Message-ID: <20250304131115.1252827-1-juliusz@wolfssl.com>

Add tls_session_ticket_ext_cb and use the new wolfSSL_set_session_ticket_ext_cb API.

Signed-off-by: Juliusz Sosinowicz <juliusz at wolfssl.com>
---
 src/crypto/tls_wolfssl.c | 75 ++++++++++++++++++++++++++++++----------
 1 file changed, 57 insertions(+), 18 deletions(-)

diff --git a/src/crypto/tls_wolfssl.c b/src/crypto/tls_wolfssl.c
index 3bf52d64eb..c6a801a2e5 100644
--- a/src/crypto/tls_wolfssl.c
+++ b/src/crypto/tls_wolfssl.c
@@ -94,7 +94,8 @@ struct tls_connection {
 #if defined(EAP_FAST) || defined(EAP_FAST_DYNAMIC) || defined(EAP_SERVER_FAST)
 	tls_session_ticket_cb session_ticket_cb;
 	void *session_ticket_cb_ctx;
-	byte session_ticket[SESSION_TICKET_LEN];
+	u8 *session_ticket;
+	size_t session_ticket_len;
 #endif
 	unsigned int ca_cert_verify:1;
 	unsigned int cert_probe:1;
@@ -545,6 +546,7 @@ void tls_connection_deinit(void *tls_ctx, struct tls_connection *conn)
 	os_free(conn->domain_match);
 	os_free(conn->peer_subject);
 	os_free(conn->check_cert_subject);
+	os_free(conn->session_ticket);
 
 	/* self */
 	os_free(conn);
@@ -2534,7 +2536,8 @@ int tls_connection_get_eap_fast_key(void *tls_ctx, struct tls_connection *conn,
 }
 
 
-#if defined(EAP_FAST) || defined(EAP_FAST_DYNAMIC) || defined(EAP_SERVER_FAST)
+#if LIBWOLFSSL_VERSION_HEX >= 0x05007002 && \
+    (defined(EAP_FAST) || defined(EAP_FAST_DYNAMIC) || defined(EAP_SERVER_FAST))
 
 int tls_connection_client_hello_ext(void *ssl_ctx, struct tls_connection *conn,
 				    int ext_type, const u8 *data,
@@ -2559,33 +2562,60 @@ static int tls_sess_sec_cb(WOLFSSL *s, void *secret, int *secret_len, void *arg)
 	int ret;
 	unsigned char client_random[RAN_LEN];
 	unsigned char server_random[RAN_LEN];
-	word32 ticket_len = sizeof(conn->session_ticket);
 
 	if (!conn || !conn->session_ticket_cb)
-		return 1;
+		return -1;
+
+	wpa_printf(MSG_DEBUG, "wolfSSL: %s", __func__);
 
 	if (wolfSSL_get_client_random(s, client_random,
 				      sizeof(client_random)) == 0 ||
 	    wolfSSL_get_server_random(s, server_random,
-				      sizeof(server_random)) == 0 ||
-	    wolfSSL_get_SessionTicket(s, conn->session_ticket,
-				      &ticket_len) != 1)
-		return 1;
-
-	if (ticket_len == 0)
-		return 0;
+				      sizeof(server_random)) == 0)
+		return -1;
 
 	ret = conn->session_ticket_cb(conn->session_ticket_cb_ctx,
-				      conn->session_ticket, ticket_len,
+				      conn->session_ticket, conn->session_ticket_len,
 				      client_random, server_random, secret);
+
+	wpa_printf(MSG_DEBUG, "wolfSSL: %s conn->session_ticket_cb: %d", __func__, ret);
+
+	os_free(conn->session_ticket);
+	conn->session_ticket = NULL;
+
 	if (ret <= 0)
-		return 1;
+		return -1;
 
 	*secret_len = SECRET_LEN;
 	return 0;
 }
 
-#endif /* EAP_FAST || EAP_FAST_DYNAMIC || EAP_SERVER_FAST */
+static int tls_session_ticket_ext_cb(SSL *s, const unsigned char *data,
+				     int len, void *arg)
+{
+	struct tls_connection *conn = arg;
+
+	if (conn == NULL || conn->session_ticket_cb == NULL)
+		return 0;
+
+	wpa_printf(MSG_DEBUG, "wolfSSL: %s: length=%d", __func__, len);
+
+	os_free(conn->session_ticket);
+	conn->session_ticket = NULL;
+
+	wpa_hexdump(MSG_DEBUG, "wolfSSL: ClientHello SessionTicket "
+		    "extension", data, len);
+
+	conn->session_ticket = os_memdup(data, len);
+	if (conn->session_ticket == NULL)
+		return 0;
+
+	conn->session_ticket_len = len;
+
+	return 1;
+}
+#endif /* LIBWOLFSSL_VERSION_HEX >= 0x05007002 &&
+ 	 	* (EAP_FAST || EAP_FAST_DYNAMIC || EAP_SERVER_FAST) */
 
 
 int tls_connection_set_session_ticket_cb(void *tls_ctx,
@@ -2593,23 +2623,32 @@ int tls_connection_set_session_ticket_cb(void *tls_ctx,
 					 tls_session_ticket_cb cb,
 					 void *ctx)
 {
-#if defined(EAP_FAST) || defined(EAP_FAST_DYNAMIC) || defined(EAP_SERVER_FAST)
+	/* wolfSSL_set_session_ticket_ext_cb added in wolfSSL 5.7.2 */
+#if LIBWOLFSSL_VERSION_HEX >= 0x05007002 && \
+    (defined(EAP_FAST) || defined(EAP_FAST_DYNAMIC) || defined(EAP_SERVER_FAST))
 	conn->session_ticket_cb = cb;
 	conn->session_ticket_cb_ctx = ctx;
 
 	if (cb) {
 		if (wolfSSL_set_session_secret_cb(conn->ssl, tls_sess_sec_cb,
-						  conn) != 1)
+				conn) != 1)
+			return -1;
+		if (wolfSSL_set_session_ticket_ext_cb(conn->ssl,
+				tls_session_ticket_ext_cb, conn) != 1)
 			return -1;
 	} else {
 		if (wolfSSL_set_session_secret_cb(conn->ssl, NULL, NULL) != 1)
 			return -1;
+		if (wolfSSL_set_session_ticket_ext_cb(conn->ssl, NULL, NULL) != 1)
+			return -1;
 	}
 
 	return 0;
-#else /* EAP_FAST || EAP_FAST_DYNAMIC || EAP_SERVER_FAST */
+#else /* LIBWOLFSSL_VERSION_HEX >= 0x05007002 &&
+	   * (EAP_FAST || EAP_FAST_DYNAMIC || EAP_SERVER_FAST) */
 	return -1;
-#endif /* EAP_FAST || EAP_FAST_DYNAMIC || EAP_SERVER_FAST */
+#endif /* LIBWOLFSSL_VERSION_HEX >= 0x05007002 &&
+ 	 	* (EAP_FAST || EAP_FAST_DYNAMIC || EAP_SERVER_FAST) */
 }
 
 
-- 
2.43.0



From juliusz at wolfssl.com  Tue Mar  4 05:19:27 2025
From: juliusz at wolfssl.com (Juliusz Sosinowicz)
Date: Tue, 4 Mar 2025 14:19:27 +0100
Subject: [PATCH 07/24] openssl: Use uncompressed format for ECC keys
In-Reply-To: <Z5--bp7YtMIRx5zN@w1.fi>
References: <20240404181630.2431991-1-juliusz@wolfssl.com>
 <20240404181630.2431991-7-juliusz@wolfssl.com> <Z5--bp7YtMIRx5zN@w1.fi>
Message-ID: <cf0a4688-9a16-47fd-ae78-8f0fd921b340@wolfssl.com>

I understand that this is a potentially breaking change but I don't see 
this change (uncompressed -> compressed) noted anywhere. If this would 
be a breaking change then the OpenSSL 3 implementation would clash with 
existing OpenSSL <3 deployments. Does the DPP work you mention only 
target the OpenSSL 3 implementation? Do you know of protocols that 
explicitly mandate one format or the other?

On 02/02/2025 19:50, Jouni Malinen wrote:
> On Thu, Apr 04, 2024 at 08:16:13PM +0200, Juliusz Sosinowicz wrote:
>> OpenSSL <3.0 uses ECC keys in the uncompressed format. We should keep it that way for compatibility. The wolfSSL backend also uses the uncompressed format.
> I don't really want to change behavior with OpenSSL for this without
> significant amount of additional testing (which I'm unlikely to find
> time for any time soon) since this area has been quite a mess in the
> past especially with the DPP requirements of various constructions there
> using either compressed or uncompressed format. In practice, if this
> were ever to be done as a generic change, there would need to be
> explicit format conversion routines in all places where a protocol
> definition mandates a specific format to be used. Testing this would
> likely need explicit checks of the correct format being used as well
> since otherwise it would be way too easy to break something subtle that
> might seem to work with some crypto libraries but would not be compliant
> with the protocol definition.
>


From Matej.Vrba at advantech.cz  Tue Mar  4 06:12:06 2025
From: Matej.Vrba at advantech.cz (Matej Vrba)
Date: Tue, 4 Mar 2025 14:12:06 +0000
Subject: [PATCH] ACS: BSS-based interference computation
Message-ID: <f030212e-ab2a-4911-a853-b46f0c0dbddf@advantech.com>

Adds a fallback BSS-based channel selection if Survey-based selection
fails. Interference factor is simply the number of BSSes on that channel.

Signed-off-by: Mat?j Vrba <matej.vrba at advantech.cz>
---
?src/ap/acs.c???????? | 39 ++++++++++++++++++++++++++++++++++++---
?src/drivers/driver.h |? 6 ++++++
?2 files changed, 42 insertions(+), 3 deletions(-)

diff --git a/src/ap/acs.c b/src/ap/acs.c
index f5b36d327..55c989fb9 100644
--- a/src/ap/acs.c
+++ b/src/ap/acs.c
@@ -54,7 +54,7 @@
? * Todo / Ideas
? * ------------
? * - implement other interference computation methods
- *?? - BSS/RSSI based
+ *?? - RSSI based
? *?? - spectral scan based
? *?? (should be possibly to hook this up with current ACS scans)
? * - add wpa_supplicant support (for P2P)
@@ -557,6 +557,8 @@ static int acs_surveys_are_sufficient(struct hostapd_iface *iface)
?
?static int acs_usable_chan(struct hostapd_channel_data *chan)
?{
+??? if (chan->interference_bss_based)
+??????? return 1;
???? return !dl_list_empty(&chan->survey_list) &&
???????? !(chan->flag & HOSTAPD_CHAN_DISABLED) &&
???????? acs_survey_list_is_sufficient(chan);
@@ -1253,14 +1255,45 @@ static int acs_study_survey_based(struct hostapd_iface *iface)
???? return 0;
?}
?
+static int acs_study_bss_based(struct hostapd_iface *iface)
+{
+??? struct wpa_scan_results???? *scan_res;
+??? unsigned int???????????????? bss_on_ch;
+??? struct hostapd_channel_data *chan;
+??? wpa_printf(MSG_DEBUG, "ACS: Trying BSS-based ACS");
+
+??? scan_res = hostapd_driver_get_scan_results(iface->bss[0]);
+??? if (scan_res == NULL) {
+??????? wpa_printf(MSG_ERROR, "ACS: Scan request failed");
+??????? hostapd_setup_interface_complete(iface, 1);
+??????? return -1;
+??? }
+
+??? for (size_t j = 0; j < iface->current_mode->num_channels; j++) {
+??????? bss_on_ch = 0;
+??????? chan = &iface->current_mode->channels[j];
+??????? for (size_t i = 0; i < scan_res->num; i++) {
+??????????? struct wpa_scan_res *bss = scan_res->res[i];
+??????????? if (bss->freq == chan->freq)
+??????????????? bss_on_ch++;
+??????? }
+??????? wpa_printf(MSG_MSGDUMP, "ACS: Interference on ch %d (%d MHz): %d", chan->chan, chan->freq, bss_on_ch);
+??????? chan->interference_factor = bss_on_ch;
+??????? chan->interference_bss_based = 1;
+??? }
+
+??? wpa_scan_results_free(scan_res);
+??? return 0;
+}
?
?static int acs_study_options(struct hostapd_iface *iface)
?{
???? if (acs_study_survey_based(iface) == 0)
???????? return 0;
+??? wpa_printf(MSG_WARNING, "ACS: survey based ACS failed");
?
-??? /* TODO: If no surveys are available/sufficient this is a good
-??? * place to fallback to BSS-based ACS */
+??? if (acs_study_bss_based(iface) == 0)
+??????? return 0;
?
???? return -1;
?}
diff --git a/src/drivers/driver.h b/src/drivers/driver.h
index 566475214..2b714b8f5 100644
--- a/src/drivers/driver.h
+++ b/src/drivers/driver.h
@@ -159,6 +159,12 @@ struct hostapd_channel_data {
???? * need to set this)
???? */
???? long double interference_factor;
+
+??? /**
+??? * interference_bss_based - Indicates that the interference was
+??? * calculated from number of BSSes
+??? */
+??? int interference_bss_based;
?#endif /* CONFIG_ACS */
?
???? /**
-- 
2.48.1


From nchernikov at maxlinear.com  Tue Mar  4 06:49:45 2025
From: nchernikov at maxlinear.com (Nikita Chernikov)
Date: Tue, 4 Mar 2025 14:49:45 +0000
Subject: [PATCH v2] wpa_auth: Reconfigure group rekey timer upon wpa_reconfig
Message-ID: <CY8PR19MB725203786307E6F679A5A960DBC82@CY8PR19MB7252.namprd19.prod.outlook.com>

>From 33be851ea54ce836c07cb4b2117b5a61da9ebaee Mon Sep 17 00:00:00 2001
From: Nikita Chernikov <nchernikov at maxlinear.com>
Date: Fri, 14 Feb 2025 18:04:28 +0530
Subject: [PATCH v2] wpa_auth: Reconfigure group rekey timer upon wpa_reconfig
To: hostap at lists.infradead.org

During BSS reload (either via ctrl iface or SIGHUP) need to reconfigure the
group rekey timer, as it might change for specific BSS via the new config file.
If not reconfigured, the previous running timer will need to expire in order to apply
the new group rekey timeout.

Fix typo in eloop_cancel_timeout of previously suggested and listed patch

Signed-off-by: Nikita Chernikov <nchernikov at maxlinear.com>
---
 src/ap/wpa_auth.c    | 14 ++++++++++++++
 1 files changed, 14 insertions(+)

diff --git a/src/ap/wpa_auth.c b/src/ap/wpa_auth.c
index ffb88a03f..7a39a7b34 100644
--- a/src/ap/wpa_auth.c
+++ b/src/ap/wpa_auth.c
@@ -652,6 +652,18 @@ static void wpa_auth_pmksa_free_cb(struct rsn_pmksa_cache_entry *entry,
 	wpa_auth_for_each_sta(wpa_auth, wpa_auth_pmksa_clear_cb, entry);
 }
 
+static void wpa_reconfig_group_rekey_timer(struct wpa_authenticator *wpa_auth)
+{
+	if (!wpa_auth)
+		return;
+
+	eloop_cancel_timeout(wpa_rekey_gtk, wpa_auth, NULL);
+
+	if (wpa_auth->conf.wpa_group_rekey) {
+		eloop_register_timeout(wpa_auth->conf.wpa_group_rekey,
+				       0, wpa_rekey_gtk, wpa_auth, NULL);
+	}
+}
 
 static int wpa_group_init_gmk_and_counter(struct wpa_authenticator *wpa_auth,
 					  struct wpa_group *group)
@@ -990,6 +1002,8 @@ int wpa_reconfig(struct wpa_authenticator *wpa_auth,
 	group->GInit = false;
 	wpa_group_sm_step(wpa_auth, group);
 
+	wpa_reconfig_group_rekey_timer(wpa_auth);
+
 	return 0;
 }
  
-- 
2.17.1



From jukka.rissanen at nordicsemi.no  Fri Mar  7 00:03:11 2025
From: jukka.rissanen at nordicsemi.no (Rissanen, Jukka)
Date: Fri, 7 Mar 2025 08:03:11 +0000
Subject: About hostap memory usage
Message-ID: <DB9PR05MB964183B32F83155125AB068195D52@DB9PR05MB9641.eurprd05.prod.outlook.com>

Hi,

I am writing this on behalf of Zephyr RTOS wifi community. We are using hostap 2.11 which is integrated to Zephyr RTOS and used as a native wifi stack. We noticed that the upgrade to v2.11 increased memory consumption and one of the reasons was Wi-Fi 7 support which is always enabled in STA mode but can be turned off in AP mode (CONFIG_IEEE80211BE option). This memory consumption is problematic in embedded devices which have limited RAM and flash available. Zephyr RTOS is made to be highly configurable and modular in order to allow user to select bits and pieces that he/she needs. So even if the user does not need Wi-Fi 7 support in STA mode, it cannot be turned off.

So our question is, if upstream would be willing to accept patches that make Wi-Fi 7 optional in STA mode?

Related to this, would it be possible to take into account the memory consumption growth for the new features? Generally, compiler is able to do a good job at dropping unused code. However, they are not able to drop unused fields in the structures. So, it would be great if the fields introduced with new features could be conditionally compiled. So that even if new hostap versions emerge, end users could upgrade to use the latest version and not expect the memory consumption to increase as the not needed features could be turned off but users could still benefit from security fixes etc.

Cheers,
Jukka



From tim at seoss.co.uk  Sun Mar 16 07:48:38 2025
From: tim at seoss.co.uk (Tim Small)
Date: Sun, 16 Mar 2025 14:48:38 +0000
Subject: [PATCH 0/1] Dbus fix build test failure (unused var)
Message-ID: <20250316144839.872145-1-tim@seoss.co.uk>

Fix a failure when running tests/build/run-build-tests.sh on Debian 12.

Tim Small (1):
  dbus: Conditionally declare local var to match usage

 wpa_supplicant/dbus/dbus_new_handlers.c | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.39.5



From tim at seoss.co.uk  Sun Mar 16 07:48:39 2025
From: tim at seoss.co.uk (Tim Small)
Date: Sun, 16 Mar 2025 14:48:39 +0000
Subject: [PATCH 1/1] dbus: Conditionally declare local var to match usage
In-Reply-To: <20250316144839.872145-1-tim@seoss.co.uk>
References: <20250316144839.872145-1-tim@seoss.co.uk>
Message-ID: <20250316144839.872145-2-tim@seoss.co.uk>

Fix dbus build test failures in some configurations (-Werror=unused-variable).

Signed-off-by: Tim Small <tim at seoss.co.uk>
---
 wpa_supplicant/dbus/dbus_new_handlers.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c b/wpa_supplicant/dbus/dbus_new_handlers.c
index e43bf83362..d9c6fafa23 100644
--- a/wpa_supplicant/dbus/dbus_new_handlers.c
+++ b/wpa_supplicant/dbus/dbus_new_handlers.c
@@ -5801,7 +5801,9 @@ dbus_bool_t wpas_dbus_getter_bss_anqp(
 	struct bss_handler_args *args = user_data;
 	struct wpa_bss *bss;
 	struct wpa_bss_anqp *anqp;
+#ifdef CONFIG_INTERWORKING
 	struct wpa_bss_anqp_elem *elem;
+#endif /* CONFIG_INTERWORKING */
 
 	bss = get_bss_helper(args, error, __func__);
 	if (!bss)
-- 
2.39.5



From n.rottgardt at gmail.com  Sun Mar 16 13:59:52 2025
From: n.rottgardt at gmail.com (Nils Rottgardt)
Date: Sun, 16 Mar 2025 21:59:52 +0100
Subject: [PATCH] wnm_ap: optional disassociation for bss_tm_req
In-Reply-To: <aa8445a9-cdf1-4cbd-81c4-93a072c55f87@gmail.com>
References: <20241130212017.593-1-n.rottgardt@gmail.com>
 <Z2w_8p62D9LC0Rb4@w1.fi> <3b54efed-ee0d-4ef5-81a2-6bc2157d7fea@gmail.com>
 <aa8445a9-cdf1-4cbd-81c4-93a072c55f87@gmail.com>
Message-ID: <0b1e101e-91d5-4b08-95a4-0d726dd43b57@gmail.com>

Hi Jouni,

any comments to this thoughts? Actually the interface is not entirely 
available as needed to control roaming at best for a wifi controller.

Cheers,

Nils

Am 07.02.2025 um 12:54 schrieb Nils Rottgardt:
> Hi Jouni,
>
> have you had time to look at this? Perhaps it could be also an option 
> to add a new call to cancel a running dissociation timer to handle 
> BSS_TM_RESP responses...could be more complex perhaps instead moving 
> the "timer" to the controller application.
>
> Cheers,
>
> Nils
>
> Am 26.12.2024 um 00:45 schrieb Nils Rottgardt:
>> "right reason code":
>>
>> This would be an option as well. I gone this way as Usteer does the 
>> disassociation on its own and it would be flexible and easy to still 
>> use this.
>>
>>
>> "avoid a disassociation part":
>>
>> From IEEE specs I know the disassociation is not played that hard. 
>> Clients have some options to handle the disassociation imminent flag 
>> and also reacts differently of the disassociation timer value is 
>> provided or not. E.g. my Intel AX201 or iPhone will roam only 
>> sometimes with disassociation imminent = false or true...the roaming 
>> behaviour changes if disassociation timer is set only. Actually 
>> Usteer using roaming with disassociation imminent = true without 
>> disassociation to handle BSS_TM_RESP. This leads into Clients 
>> ignoring the BSS_TM_REQ.
>>
>> - disassociation imminent not set: a suggestion to roam, client 
>> handles it with very low priority
>>
>> - disassociation imminent set, disassociation timer not set: the 
>> client should roam/react on the roaming request as it will be 
>> disassociated sometimes in the future. Actually Usteer using this 
>> flag without using disassociation timer. This leads into an issue as 
>> according IEEE this tells the client that it will be disassociated to 
>> a random time in the future. Some clients like Intel AX201 or iPhone 
>> will mostly handle it like disassociation imminent = false.
>>
>> - disassociation imminent set, disassociation timer set: the client 
>> is told the exact time after it will be disassociated if it does not 
>> roam/react. As it is set explicitly Intel AX201 and iPhone will 
>> follow this BSS_TM_REQ instantly. Sometimes they answers with a 
>> BSS_TM_RESP different from 0 like BSS_TM_RESP 2 (denied) or 6 (Delay 
>> requested). Then it should be allowed to stay but this is not 
>> possible as it will be hardly disassociated by hostap. This leads 
>> into stuttering with e.g. VoIP sessions if the client cannot 
>> associate with the new AP somehow...
>>
>> Usteer implemented a workaround not setting disassociation timer and 
>> force the disassociation on its own but clients reacts differently 
>> knowing the exact time... 
>> https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/201015-802-11v-Basic-Service-Set-BSS-on-AireO.html#anc10
>>
>>
>> My idea was to do the whole disassociation handling in Usteer so if 
>> the client responded with a deny nothing has to be done. If the 
>> client does not answer it will be disassociated with UBUS: del_client 
>> command. I did not checked what is exactly called in hostap but it is 
>> hostapd_drv_sta_deauth and ap_sta_deauthenticate.
>>
>>
>> To sum it up: It is crucial for some Wifi clients to have 
>> disassociation timer published in the BSS_TM_REQ frame as it leads 
>> into a higher priority. Disassociation imminent is unrewarding 
>> without...but is using disassociation timer the BSS_TM_RESP is 
>> senseless as the disassociation is hardcoded in hostap and cannot be 
>> stopped.
>>
>>
>>
>> Am 25.12.2024 um 18:25 schrieb Jouni Malinen:
>>> On Sat, Nov 30, 2024 at 10:20:17PM +0100, Nils Hendrik Rottgardt wrote:
>>>> To give controllers like usteer or DAWN the opportunity to 
>>>> disassociate
>>>> with the right reason code and also avoid a disassociation if it is
>>>> not neccessary.
>>> For the "right reason code" part, I would prefer to have an option for
>>> such external components to provide that reason code with the 
>>> command to
>>> send the BSS Transition Management Request frame instead of expecting
>>> them to handle the timeout.
>>>
>>> For the "avoid a disassociation part", why would the AP send a
>>> notification of imminent disassociation if it is not going to
>>> disassociate the STA? If I remember correctly, the disassociation is
>>> actually required to happen at least for some cases, so it would be 
>>> good
>>> to understand why there would be desire to avoid that.
>>>
>>> Furthermore, this patch does not actually provide any means for using
>>> this proposed functionality since nothing here calls
>>> wnm_send_bss_tm_req_disassoc() with disassoc = false. Even if such
>>> option were added, it should also be noted that set_disassoc_timer()
>>> does two things: removes a cached PMKSA for the STA (to force new
>>> association) and starts a timer to disassociate the STA. Is there 
>>> really
>>> need to skip that first part as well?
>>>


From benjamin at sipsolutions.net  Tue Mar 18 03:19:56 2025
From: benjamin at sipsolutions.net (Benjamin Berg)
Date: Tue, 18 Mar 2025 11:19:56 +0100
Subject: [PATCH 2/2] SAE: explicitly clear SAE(k)
In-Reply-To: <20250318101957.130599-1-benjamin@sipsolutions.net>
References: <20250318101957.130599-1-benjamin@sipsolutions.net>
Message-ID: <20250318101957.130599-3-benjamin@sipsolutions.net>

From: Benjamin Berg <benjamin.berg at intel.com>

The code never cleared SAE(k) and the data could remain on the stack for
a longer period of time. This caused a test failure when running with
ASAN enabled.

Explicitly clear the variable to ensure no data is leaked.

Signed-off-by: Benjamin Berg <benjamin.berg at intel.com>
---
 src/common/sae.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/common/sae.c b/src/common/sae.c
index 801f36301d..8005095fc6 100644
--- a/src/common/sae.c
+++ b/src/common/sae.c
@@ -1670,12 +1670,17 @@ fail:
 int sae_process_commit(struct sae_data *sae)
 {
 	u8 k[SAE_MAX_PRIME_LEN];
+	int ret = 0;
+
 	if (sae->tmp == NULL ||
 	    (sae->tmp->ec && sae_derive_k_ecc(sae, k) < 0) ||
 	    (sae->tmp->dh && sae_derive_k_ffc(sae, k) < 0) ||
 	    sae_derive_keys(sae, k) < 0)
-		return -1;
-	return 0;
+		ret = -1;
+
+	forced_memzero(k, SAE_MAX_PRIME_LEN);
+
+	return ret;
 }
 
 
-- 
2.48.1



From benjamin at sipsolutions.net  Tue Mar 18 03:19:54 2025
From: benjamin at sipsolutions.net (Benjamin Berg)
Date: Tue, 18 Mar 2025 11:19:54 +0100
Subject: [PATCH 0/2] ASAN related fixes
Message-ID: <20250318101957.130599-1-benjamin@sipsolutions.net>

From: Benjamin Berg <benjamin.berg at intel.com>

Hi,

I did some trail runs to enable ASAN internally for the hwsim tests
(inside a UML time-travel environment). Most issues that came up seem
already fixed upstream, but these two seem to be missing still.

Note that to run it inside UML you should use a 6.14 kernel (6.13 might
also work). I also added a patch to avoid a large slowdown due to a
broken userspace spinlock in ASAN:
  https://patchwork.ozlabs.org/project/linux-um/patch/20250314130815.226872-1-benjamin at sipsolutions.net/

Other than that, I was setting these options:

UBSAN_OPTIONS=halt_on_error=1:print_stacktrace=1:log_path=/some/path
ASAN_OPTIONS=halt_on_error=1:print_stacktrace=1:log_path=/some/path:quarantine_size_mb=64

Using a log path is useful as the sanitizers try to log to stderr, but
e.g. the EHT tests launch hostapd as a daemon and do not have any stderr
available.

Reducing the quarantine_size_mb allowed me to run all tests in our setup
with 4 GiB of memory available to the VMs.

Benjamin

Benjamin Berg (2):
  nl80211: fix use after free of bss
  SAE: explicitly clear SAE(k)

 src/common/sae.c             | 9 +++++++--
 src/drivers/driver_nl80211.c | 4 +++-
 2 files changed, 10 insertions(+), 3 deletions(-)

-- 
2.48.1



From benjamin at sipsolutions.net  Tue Mar 18 03:19:55 2025
From: benjamin at sipsolutions.net (Benjamin Berg)
Date: Tue, 18 Mar 2025 11:19:55 +0100
Subject: [PATCH 1/2] nl80211: fix use after free of bss
In-Reply-To: <20250318101957.130599-1-benjamin@sipsolutions.net>
References: <20250318101957.130599-1-benjamin@sipsolutions.net>
Message-ID: <20250318101957.130599-2-benjamin@sipsolutions.net>

From: Benjamin Berg <benjamin.berg at intel.com>

This was reported by ASAN, the bss variable was just freed a bit
earlier.

Signed-off-by: Benjamin Berg <benjamin.berg at intel.com>
---
 src/drivers/driver_nl80211.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
index 56a412732d..a854b8d901 100644
--- a/src/drivers/driver_nl80211.c
+++ b/src/drivers/driver_nl80211.c
@@ -10973,6 +10973,8 @@ static int driver_nl80211_link_remove(void *priv, enum wpa_driver_if_type type,
 		drv->ctx = bss->ctx;
 
 	if (!bss->valid_links) {
+		void *ctx = bss->ctx;
+
 		wpa_printf(MSG_DEBUG,
 			   "nl80211: No more links remaining, so remove interface");
 		ret = wpa_driver_nl80211_if_remove(bss, type, ifname);
@@ -10980,7 +10982,7 @@ static int driver_nl80211_link_remove(void *priv, enum wpa_driver_if_type type,
 			return ret;
 
 		/* Notify that the MLD interface is removed */
-		wpa_supplicant_event(bss->ctx, EVENT_MLD_INTERFACE_FREED, NULL);
+		wpa_supplicant_event(ctx, EVENT_MLD_INTERFACE_FREED, NULL);
 	}
 
 	return 0;
-- 
2.48.1



From j at w1.fi  Tue Mar 18 14:00:13 2025
From: j at w1.fi (Jouni Malinen)
Date: Tue, 18 Mar 2025 23:00:13 +0200
Subject: [PATCH v2] wpa_auth: Reconfigure group rekey timer upon
 wpa_reconfig
In-Reply-To: <CY8PR19MB725203786307E6F679A5A960DBC82@CY8PR19MB7252.namprd19.prod.outlook.com>
References: <CY8PR19MB725203786307E6F679A5A960DBC82@CY8PR19MB7252.namprd19.prod.outlook.com>
Message-ID: <Z9ne3ZpBoHKtfJcL@w1.fi>

On Tue, Mar 04, 2025 at 02:49:45PM +0000, Nikita Chernikov wrote:
> During BSS reload (either via ctrl iface or SIGHUP) need to reconfigure the
> group rekey timer, as it might change for specific BSS via the new config file.
> If not reconfigured, the previous running timer will need to expire in order to apply
> the new group rekey timeout.

Shouldn't this be done only if the wpa_group_rekey configuration has
actually been changed? If this is done for all reconfiguration cases,
this would seem to push out group rekeying unexpectedly.

With the AP MLD changes, there is no a concept of a primary
authenticator and the wpa_group_rekey timeout is used only on that link.
It would seem like that would have an impact for this as well, i.e., the
timeout should be registered only for the primary auithenticator.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Tue Mar 18 14:13:39 2025
From: j at w1.fi (Jouni Malinen)
Date: Tue, 18 Mar 2025 23:13:39 +0200
Subject: [PATCH] ACS: BSS-based interference computation
In-Reply-To: <f030212e-ab2a-4911-a853-b46f0c0dbddf@advantech.com>
References: <f030212e-ab2a-4911-a853-b46f0c0dbddf@advantech.com>
Message-ID: <Z9niA8urvSfSpNfG@w1.fi>

On Tue, Mar 04, 2025 at 02:12:06PM +0000, Matej Vrba wrote:
> Adds a fallback BSS-based channel selection if Survey-based selection
> fails. Interference factor is simply the number of BSSes on that channel.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Tue Mar 18 14:13:55 2025
From: j at w1.fi (Jouni Malinen)
Date: Tue, 18 Mar 2025 23:13:55 +0200
Subject: [PATCH 1/1] dbus: Conditionally declare local var to match usage
In-Reply-To: <20250316144839.872145-2-tim@seoss.co.uk>
References: <20250316144839.872145-1-tim@seoss.co.uk>
 <20250316144839.872145-2-tim@seoss.co.uk>
Message-ID: <Z9niE3Co7BfG0cTl@w1.fi>

On Sun, Mar 16, 2025 at 02:48:39PM +0000, Tim Small wrote:
> Fix dbus build test failures in some configurations (-Werror=unused-variable).

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From j at w1.fi  Tue Mar 18 14:14:17 2025
From: j at w1.fi (Jouni Malinen)
Date: Tue, 18 Mar 2025 23:14:17 +0200
Subject: [PATCH 0/2] ASAN related fixes
In-Reply-To: <20250318101957.130599-1-benjamin@sipsolutions.net>
References: <20250318101957.130599-1-benjamin@sipsolutions.net>
Message-ID: <Z9niKVT63smcY2dT@w1.fi>

On Tue, Mar 18, 2025 at 11:19:54AM +0100, Benjamin Berg wrote:
> Benjamin Berg (2):
>   nl80211: fix use after free of bss
>   SAE: explicitly clear SAE(k)

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From michael-cy.lee at mediatek.com  Wed Mar 19 17:53:28 2025
From: michael-cy.lee at mediatek.com (Michael-CY Lee)
Date: Thu, 20 Mar 2025 08:53:28 +0800
Subject: [PATCH] AP MLD: always process every link in association request
Message-ID: <20250320005328.3936844-1-michael-cy.lee@mediatek.com>

Error might happen when handling one of the link(s) in association
request, but immediately returning causes missing of status code of
the unprocessed link(s) in association response.

Always processing every link in association request ensures that every
link has it status code in the association response.

Signed-off-by: Michael-CY Lee <michael-cy.lee at mediatek.com>
Signed-off-by: Money Wang <money.wang at mediatek.com>
---
 src/ap/ieee802_11.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/ap/ieee802_11.c b/src/ap/ieee802_11.c
index 523e0a322..4f63182a1 100644
--- a/src/ap/ieee802_11.c
+++ b/src/ap/ieee802_11.c
@@ -4911,6 +4911,7 @@ int hostapd_process_assoc_ml_info(struct hostapd_data *hapd,
 {
 #ifdef CONFIG_IEEE80211BE
 	unsigned int i;
+	int ret = 0;
 
 	if (!hostapd_is_mld_ap(hapd))
 		return 0;
@@ -4950,12 +4951,12 @@ int hostapd_process_assoc_ml_info(struct hostapd_data *hapd,
 			if (ieee80211_ml_process_link(bss, sta, link,
 						      ies, ies_len, reassoc,
 						      offload))
-				return -1;
+				ret = -1;
 		}
 	}
 #endif /* CONFIG_IEEE80211BE */
 
-	return 0;
+	return ret;
 }
 
 
-- 
2.25.1



From j at w1.fi  Thu Mar 20 14:26:48 2025
From: j at w1.fi (Jouni Malinen)
Date: Thu, 20 Mar 2025 23:26:48 +0200
Subject: [PATCH] AP MLD: always process every link in association request
In-Reply-To: <20250320005328.3936844-1-michael-cy.lee@mediatek.com>
References: <20250320005328.3936844-1-michael-cy.lee@mediatek.com>
Message-ID: <Z9yIGJjM6Xw0bQTz@w1.fi>

On Thu, Mar 20, 2025 at 08:53:28AM +0800, Michael-CY Lee wrote:
> Error might happen when handling one of the link(s) in association
> request, but immediately returning causes missing of status code of
> the unprocessed link(s) in association response.
> 
> Always processing every link in association request ensures that every
> link has it status code in the association response.

Thanks, applied with non-CONFIG_IEEE80211BE builds fixed.

-- 
Jouni Malinen                                            PGP id EFC895FA


From adrian at freebsd.org  Sat Mar 22 10:45:39 2025
From: adrian at freebsd.org (Adrian Chadd)
Date: Sat, 22 Mar 2025 10:45:39 -0700
Subject: gcmp priority!
Message-ID: <CAJ-VmonrsuXJDjvvPp0goWVbnOSpCSjL445M_O9Oq5hLPzX=5Q@mail.gmail.com>

hi!

I'm adding GCMP support to FreeBSD. I've got the crypto support in
net80211 working and all the driver caps / cipher caps / etc all
setup. And yes I'm doing this on 11n/11ac NICs as net80211 don't
currently support WPA3/MFP, 11ad, 11ax, etc in the stack (but yes,
this is all along the trajectory for WPA3/MFP.)

Anyway! I've noticed that while yes I can add GCMP to hostapd and
wpa_supplicant configs, wpa_supplicant REALLY only wants to negotiate
GCMP if it's the only cipher listed. If there's GCMP and CCMP
available, wpa_supplicant reliably chooses CCMP.

I think i've traced down where in the source this is happening, as
it's choosing CCMP for default for non-11ad, and GCMP default for
11ad.

My questions however are with how the 802.11 specification
could/should allow for cipher choices / priorities.

* I haven't found anything in 802.11-2020 section 12 (security) that
indicates a formal cipher priority. Is there a formal cipher priority?
Is there anything stopping wpa_supplicant from choosing GCMP over CCMP
if an AP advertises both?
* Is it legal to have GCMP as a pairwise key and CCMP as a group key?
* Has anyone else tried this, and found weird interoperability issues?

Thanks!


-adrian

(adrian at freebsd.org)


From Matej.Vrba at advantech.cz  Tue Mar 25 06:25:09 2025
From: Matej.Vrba at advantech.cz (Matej Vrba)
Date: Tue, 25 Mar 2025 13:25:09 +0000
Subject: [PATCH] Fix ACS when using 20MHz channels in 6GHz
Message-ID: <9d962cd4-60e7-4cd0-ad17-d8b9fc288619@advantech.com>

When configured to use ACS with 20MHz channels, hostapd incorrectly rejects
half of the available channels with an error messages "Channel XX: not
allowed as primary channel for 40 MHz bandwidth." This includes all PSC
channels.

Signed-off-by: Mat?j Vrba <matej.vrba at advantech.cz>
---
?src/ap/acs.c | 59 ++++++++++++++++++++++++++++++++--------------------
?1 file changed, 36 insertions(+), 23 deletions(-)

diff --git a/src/ap/acs.c b/src/ap/acs.c
index 44d083684..4eb44780c 100644
--- a/src/ap/acs.c
+++ b/src/ap/acs.c
@@ -242,6 +242,12 @@
? * [1] http://en.wikipedia.org/wiki/Near_and_far_field
? */
?
+// Corresponds to "Behavior limits set" in 802.11-2020 annex E
+enum behavior_limitation {
+? BLIMIT_NONE,
+? BLIMIT_PRIMARY_CH_LOWER,
+};
+
?enum bw_type {
??? ACS_BW40,
??? ACS_BW80,
@@ -439,17 +445,22 @@ acs_survey_chan_interference_factor(struct hostapd_iface *iface,
?
?
?static bool acs_usable_bw_chan(const struct hostapd_channel_data *chan,
-????????????????? enum bw_type bw)
+????????????????? enum bw_type bw, enum behavior_limitation limit)
?{
-?? unsigned int i = 0;
-
-?? while (bw_desc[bw][i].first != -1) {
-?????? if (chan->freq == bw_desc[bw][i].first)
-?????????? return true;
-?????? i++;
+?? switch (limit) {
+?????? case BLIMIT_NONE:
+?????????? for (unsigned int i = 0; bw_desc[bw][i].first != -1; i++)
+?????????????? if (chan->freq == bw_desc[bw][i].first || chan->freq == bw_desc[bw][i].last)
+?????????????????? return true;
+?????????? break;
+?????? case BLIMIT_PRIMARY_CH_LOWER:
+?????????? for (unsigned int i = 0; bw_desc[bw][i].first != -1; i++)
+?????????????? if (chan->freq == bw_desc[bw][i].first)
+?????????????????? return true;
+?????????? break;
??? }
?
-?? return false;
+? return false;
?}
?
?
@@ -797,19 +808,19 @@ acs_usable_bw320_chan(struct hostapd_iface *iface,
??? *bw320_offset = 0;
??? switch (conf_bw320_offset) {
??? case 1:
-?????? if (acs_usable_bw_chan(chan, ACS_BW320_1))
+?????? if (acs_usable_bw_chan(chan, ACS_BW320_1, BLIMIT_PRIMARY_CH_LOWER))
??????????? *bw320_offset = 1;
??????? break;
??? case 2:
-?????? if (acs_usable_bw_chan(chan, ACS_BW320_2))
+?????? if (acs_usable_bw_chan(chan, ACS_BW320_2, BLIMIT_PRIMARY_CH_LOWER))
??????????? *bw320_offset = 2;
??????? break;
??? case 0:
??? default:
??????? conf_bw320_offset = 0;
-?????? if (acs_usable_bw_chan(chan, ACS_BW320_1))
+?????? if (acs_usable_bw_chan(chan, ACS_BW320_1, BLIMIT_PRIMARY_CH_LOWER))
??????????? *bw320_offset = 1;
-?????? else if (acs_usable_bw_chan(chan, ACS_BW320_2))
+?????? else if (acs_usable_bw_chan(chan, ACS_BW320_2, BLIMIT_PRIMARY_CH_LOWER))
??????????? *bw320_offset = 2;
??????? break;
??? }
@@ -889,15 +900,17 @@ acs_find_ideal_chan_mode(struct hostapd_iface *iface,
?
??????? /* HT40 on 5 GHz has a limited set of primary channels as per
???????? * 11n Annex J */
-?????? if (mode->mode == HOSTAPD_MODE_IEEE80211A &&
-?????????? ((iface->conf->ieee80211n &&
-???????????? iface->conf->secondary_channel) ||
-??????????? is_6ghz_freq(chan->freq)) &&
-?????????? !acs_usable_bw_chan(chan, ACS_BW40)) {
-?????????? wpa_printf(MSG_DEBUG,
-????????????????? "ACS: Channel %d: not allowed as primary channel for 40 MHz bandwidth",
-????????????????? chan->chan);
-?????????? continue;
+?????? if (is_6ghz_freq(chan->freq)) {
+?????????? if (iface->conf->op_class == 132 && !acs_usable_bw_chan(chan, ACS_BW40, BLIMIT_NONE)) {
+?????????????? wpa_printf(MSG_DEBUG, "ACS: Channel %d: not allowed as primary channel for 40 MHz bandwidth in 6Ghz band", chan->chan);
+?????????????? continue;
+?????????? }
+?????? } else {
+?????????? if (mode->mode == HOSTAPD_MODE_IEEE80211A && ((iface->conf->ieee80211n && iface->conf->secondary_channel)) &&
+?????????????????? !acs_usable_bw_chan(chan, ACS_BW40, BLIMIT_PRIMARY_CH_LOWER)) {
+?????????????? wpa_printf(MSG_DEBUG, "ACS: Channel %d: not allowed as primary channel for 40 MHz bandwidth", chan->chan);
+?????????????? continue;
+?????????? }
??????? }
?
??????? if (mode->mode == HOSTAPD_MODE_IEEE80211A &&
@@ -905,7 +918,7 @@ acs_find_ideal_chan_mode(struct hostapd_iface *iface,
???????????? iface->conf->ieee80211be)) {
??????????? if (hostapd_get_oper_chwidth(iface->conf) ==
??????????????? CONF_OPER_CHWIDTH_80MHZ &&
-?????????????? !acs_usable_bw_chan(chan, ACS_BW80)) {
+?????????????? !acs_usable_bw_chan(chan, ACS_BW80, BLIMIT_PRIMARY_CH_LOWER)) {
??????????????? wpa_printf(MSG_DEBUG,
?????????????????????? "ACS: Channel %d: not allowed as primary channel for 80 MHz bandwidth",
?????????????????????? chan->chan);
@@ -914,7 +927,7 @@ acs_find_ideal_chan_mode(struct hostapd_iface *iface,
?
??????????? if (hostapd_get_oper_chwidth(iface->conf) ==
??????????????? CONF_OPER_CHWIDTH_160MHZ &&
-?????????????? !acs_usable_bw_chan(chan, ACS_BW160)) {
+?????????????? !acs_usable_bw_chan(chan, ACS_BW160, BLIMIT_PRIMARY_CH_LOWER)) {
??????????????? wpa_printf(MSG_DEBUG,
?????????????????????? "ACS: Channel %d: not allowed as primary channel for 160 MHz bandwidth",
?????????????????????? chan->chan);
-- 
2.49.0


From nico.escande at gmail.com  Tue Mar 25 08:54:59 2025
From: nico.escande at gmail.com (Nicolas Escande)
Date: Tue, 25 Mar 2025 16:54:59 +0100
Subject: [PATCH] Fix ACS when using 20MHz channels in 6GHz
In-Reply-To: <9d962cd4-60e7-4cd0-ad17-d8b9fc288619@advantech.com>
References: <9d962cd4-60e7-4cd0-ad17-d8b9fc288619@advantech.com>
Message-ID: <D8PGWH6F4C7C.DJJIXW8QRRLH@gmail.com>

On Tue Mar 25, 2025 at 2:25 PM CET, Matej Vrba wrote:
> When configured to use ACS with 20MHz channels, hostapd incorrectly rejects
> half of the available channels with an error messages "Channel XX: not
> allowed as primary channel for 40 MHz bandwidth." This includes all PSC
> channels.
>

Hello,

If I read the code right, it seems that your problem comes from the fact that
in acs_find_ideal_chan_mode() around line 92 

		if (mode->mode == HOSTAPD_MODE_IEEE80211A &&
		    ((iface->conf->ieee80211n &&
		      iface->conf->secondary_channel) ||
		     is_6ghz_freq(chan->freq)) &&
		    !acs_usable_bw_chan(chan, ACS_BW40)) {

we assume that on 6GHz we try at least to do 40MHz wide operation.

Even though the code iterates over each channel, we then wrongly discard all
channels that are not the first ones of a 40MHZ block (so all PSC channels)

So for me there are two good possible fixes:

  - either we change the above mentionned check to actually check the configured
  operational bandwidth with hostapd_get_oper_chwidth() (like in the
  other cases after this one that handles 80/160/320)

  - or we stop using this hostapd_get_oper_chwidth() nonsense and use the 'bw'
  argument (which as been validated before) and just check for that instead in
  all cases

Anyway for me your way of doing things is horrible. We complexify
acs_usable_bw_chan(), add special cases to acs_find_ideal_chan_mode() and make
the ACS code more spaghetti / less generic.

Thanks


From gubertoli at gmail.com  Tue Mar 25 11:19:32 2025
From: gubertoli at gmail.com (Gustavo Bertoli)
Date: Tue, 25 Mar 2025 19:19:32 +0100
Subject: [PATCH] hostapd_cli: Add newline to command output
Message-ID: <20250325181932.9960-1-gubertoli@gmail.com>

This patch ensures that output printed by hostapd_cli commands is
terminated with a newline character. The lack of newline caused
DPP-related command outputs ? when run via hostapd_cli or wpa_cli ?
to appear concatenated or be misinterpreted in scripting or terminal
environments.

For example, running a DPP command like dpp_bootstrap_get_uri would
print the output without a trailing newline, making it harder to
parse or read.

Signed-off-by: Gustavo Bertoli <gubertoli at gmail.com>
---
 hostapd/hostapd_cli.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hostapd/hostapd_cli.c b/hostapd/hostapd_cli.c
index 57702d93b..4dee54cba 100644
--- a/hostapd/hostapd_cli.c
+++ b/hostapd/hostapd_cli.c
@@ -220,7 +220,7 @@ static int _wpa_ctrl_command(struct wpa_ctrl *ctrl, const char *cmd, int print)
 	}
 	if (print) {
 		buf[len] = '\0';
-		printf("%s", buf);
+		printf("%s\n", buf);
 	}
 	return 0;
 }
-- 
2.43.0



From adam.baumann at morsemicro.com  Wed Mar 26 19:57:27 2025
From: adam.baumann at morsemicro.com (Adam Baumann)
Date: Thu, 27 Mar 2025 13:57:27 +1100
Subject: [PATCH] Stop scheduled scans from blocking the DPP PB discovery scan
Message-ID: <20250327025727.779395-1-adam.baumann@morsemicro.com>

DPP PB interactions cannot start during a scheduled scan as the initial
discovery scan will be blocked indefinitely. This can be fixed by
canceling an ongoing scheduled scan before performing the DPP PB
discovery scan.

Signed-off-by: Adam Baumann <adam.baumann at morsemicro.com>
---
 wpa_supplicant/dpp_supplicant.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/wpa_supplicant/dpp_supplicant.c b/wpa_supplicant/dpp_supplicant.c
index 4044b47dd..a615bf300 100644
--- a/wpa_supplicant/dpp_supplicant.c
+++ b/wpa_supplicant/dpp_supplicant.c
@@ -5733,6 +5733,7 @@ int wpas_dpp_push_button(struct wpa_supplicant *wpa_s, const char *cmd)
 		   "DPP: Scan to create channel list for PB discovery");
 	wpa_s->scan_req = MANUAL_SCAN_REQ;
 	wpa_s->scan_res_handler = wpas_dpp_pb_scan_res_handler;
+	wpa_supplicant_cancel_sched_scan(wpa_s);
 	wpa_supplicant_req_scan(wpa_s, 0, 0);
 	wpa_msg(wpa_s, MSG_INFO, DPP_EVENT_PB_STATUS "started");
 	return 0;
-- 
2.34.1



From j at w1.fi  Thu Mar 27 13:39:03 2025
From: j at w1.fi (Jouni Malinen)
Date: Thu, 27 Mar 2025 22:39:03 +0200
Subject: gcmp priority!
In-Reply-To: <CAJ-VmonrsuXJDjvvPp0goWVbnOSpCSjL445M_O9Oq5hLPzX=5Q@mail.gmail.com>
References: <CAJ-VmonrsuXJDjvvPp0goWVbnOSpCSjL445M_O9Oq5hLPzX=5Q@mail.gmail.com>
Message-ID: <Z-W3Zys0j00BAI9N@w1.fi>

On Sat, Mar 22, 2025 at 10:45:39AM -0700, Adrian Chadd wrote:
> Anyway! I've noticed that while yes I can add GCMP to hostapd and
> wpa_supplicant configs, wpa_supplicant REALLY only wants to negotiate
> GCMP if it's the only cipher listed. If there's GCMP and CCMP
> available, wpa_supplicant reliably chooses CCMP.

That is not really a completely accurate description.. wpa_supplicant
prefers 256-bit version of CCMP and GCMP over 128-bit versions of
either. In other words, GCMP-256 will be selected over CCMP-128.

It should be noted that there is practically no deployment of CCMP-256
and deployment of GCMP-128 is limited to 60 GHz cases. In other words,
on 2.4, 5, and 6 GHz bands, only CCMP-128 and GCMP-256 are used vast
majority of deployments. Between those options, wpa_supplicant will
prefer GCMP-256 over CCMP-128 if both are allowed. In other words, I
think what you are describing here is quite a theoretical question.

> I think i've traced down where in the source this is happening, as
> it's choosing CCMP for default for non-11ad, and GCMP default for
> 11ad.

No, the RSNE default values for omitted fields has nothing to do with
this. wpa_pick_pairwise_cipher() is the place where the selection
happens. It is currently picking the first available cipher in this
order: CCMP-256, GCMP-256, CCMP-128, GCMP-128. I don't think there was
really any particular reason for this order as far as CCMP vs. GCMP is
concerned, i.e., this just happened to be the case when I added support
for GCMP in 2012.

Preferring the 256-bit variants over 128-bit variants is by design, but
GCMP vs. CCMP is arbitrary since there is no significant difference in
security. GCMP is more efficient for hardware implementation, so there
is a good reason to moving to it for newer cases and that is indeed what
is happening in practice since CCMP-256 is not being deployed.

> My questions however are with how the 802.11 specification
> could/should allow for cipher choices / priorities.
> 
> * I haven't found anything in 802.11-2020 section 12 (security) that
> indicates a formal cipher priority. Is there a formal cipher priority?

Not in the IEEE 802.11 standard (and not in the Wi-Fi Alliance WPA3
specification either).

> Is there anything stopping wpa_supplicant from choosing GCMP over CCMP
> if an AP advertises both?

As far as the protocol or security properties are concerned, not really.
As far as likelihood of hitting interop issues is concerned, I would
continue to prefer CCMP-128 over GCMP-128 on 2.4/5/6 GHz since GCMP-128
has limited very limited testing there. One could argue that with that
same logic, wpa_supplicant should preferred GCMP-256 over CCMP-256 and
that would seem like a reasonable change, i.e.,
wpa_pick_pairwise_cipher() could be modified to use this priority order:
GCMP-256 CCMP-256 CCMP-128 GCMP-128

> * Is it legal to have GCMP as a pairwise key and CCMP as a group key?

Yes

> * Has anyone else tried this, and found weird interoperability issues?

GCMP-256 as the pairwise cipher and CCMP-128 as the group cipher is
something that is quite likely used in many, if not most, Wi-Fi 7
deployments, so at least as far as Wi-Fi 7 enabled devices are
concerned, this is likely to work. There might be some theoretical
issues with older devices, but such devices would not likely support
GCMP-256 and that combined with GCMP-128 not being deployed makes this
likely worth not much consideration.

-- 
Jouni Malinen                                            PGP id EFC895FA


From vic.michel.github at gmail.com  Thu Mar 27 21:05:04 2025
From: vic.michel.github at gmail.com (Victor Michel)
Date: Thu, 27 Mar 2025 21:05:04 -0700
Subject: Disabling P2P
Message-ID: <CAA1PksTmqDB=8N_e-KPAojqUf=EU-F1YAM1gP5g=Vy7our3vwA@mail.gmail.com>

Hello,

Context: I am working on some automation which involves wpa_supplicant
and NetworkManager.
My symptoms are that NetworkManager always creates a p2p device (seen
in `nmcli dev`), which I would like to avoid for automation purposes.
NetworkManager does this because wpa_supplicant says that the wlan
device has P2P capabilities.

My initial understanding was that I could avoid that by setting
p2p_disabled=1 in wpa_supplicant config. However, this flag does not
apply to newly-created interfaces. So when NetworkManager recreates
the interface, the 'disabled' check always evaluates to false, which
causes the 'p2p' flag to be set when NetworkManager examines it
through dbus. This is the relevant part:
https://w1.fi/cgit/hostap/tree/wpa_supplicant/dbus/dbus_new_handlers.c#n3538

I experimented a bit with wpa_cli as well - I don't see a way to
configure wpa_supplicant to never advertise p2p capabilities for
newly-created interfaces

* `wpa_cli set p2p_disabled 1` sets `wpa_s->conf->p2p_disabled` which
is checked in the dbus handler, but newly-created interfaces obviously
don't inherit that flag
* `wpa_cli p2p_set disabled 1` sets `wpa_s->global->p2p_disabled`
which is not checked in the dbus new handler linked above (I'm also
not sure if it can be set through a config file)


I am likely misunderstanding a few things (I am entirely new to this
code base) - but am wondering whether there is a way to achieve what I
want? I am unsure whether wpa_supplicant really is working as
expected. Maybe the solution would simply be to have NetworkManager
have its own p2p_disabled setting instead of relying entirely on
wpa_supplicant.

Any advice welcome

Thanks!


From j at w1.fi  Fri Mar 28 01:58:28 2025
From: j at w1.fi (Jouni Malinen)
Date: Fri, 28 Mar 2025 10:58:28 +0200
Subject: [PATCH] Stop scheduled scans from blocking the DPP PB discovery
 scan
In-Reply-To: <20250327025727.779395-1-adam.baumann@morsemicro.com>
References: <20250327025727.779395-1-adam.baumann@morsemicro.com>
Message-ID: <Z-ZktK0Ab2CuNV62@w1.fi>

On Thu, Mar 27, 2025 at 01:57:27PM +1100, Adam Baumann wrote:
> DPP PB interactions cannot start during a scheduled scan as the initial
> discovery scan will be blocked indefinitely. This can be fixed by
> canceling an ongoing scheduled scan before performing the DPP PB
> discovery scan.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


From jukka.rissanen at nordicsemi.no  Mon Mar 31 00:47:52 2025
From: jukka.rissanen at nordicsemi.no (Rissanen, Jukka)
Date: Mon, 31 Mar 2025 07:47:52 +0000
Subject: About hostap memory usage
In-Reply-To: <DB9PR05MB9641CE39398D52F06B646F4295D52@DB9PR05MB9641.eurprd05.prod.outlook.com>
References: <DB9PR05MB9641CE39398D52F06B646F4295D52@DB9PR05MB9641.eurprd05.prod.outlook.com>
Message-ID: <DB9PR05MB9641272C2C03F7F12E6C3E0295AD2@DB9PR05MB9641.eurprd05.prod.outlook.com>

Hi,

is there any comment to my earlier question about adding more configurability to supplicant in STA mode?

Cheers,
Jukka

________________________________________
From: Rissanen, Jukka
Sent: Friday, 7 March 2025 9.57
To: hostap at lists.infradead.org
Subject: About hostap memory usage

Hi,

I am writing this on behalf of Zephyr RTOS wifi community. We are using hostap 2.11 which is integrated to Zephyr RTOS and used as a native wifi stack. We noticed that the upgrade to v2.11 increased memory consumption and one of the reasons was Wi-Fi 7 support which is always enabled in STA mode but can be turned off in AP mode (CONFIG_IEEE80211BE option). This memory consumption is problematic in embedded devices which have limited RAM and flash available. Zephyr RTOS is made to be highly configurable and modular in order to allow user to select bits and pieces that he/she needs. So even if the user does not need Wi-Fi 7 support in STA mode, it cannot be turned off.

So our question is, if upstream would be willing to accept patches that make Wi-Fi 7 optional in STA mode?

Related to this, would it be possible to take into account the memory consumption growth for the new features? Generally, compiler is able to do a good job at dropping unused code. However, they are not able to drop unused fields in the structures. So, it would be great if the fields introduced with new features could be conditionally compiled. So that even if new hostap versions emerge, end users could upgrade to use the latest version and not expect the memory consumption to increase as the not needed features could be turned off but users could still benefit from security fixes etc.

Cheers,
Jukka




From zihan.yan at hpe.com  Mon Mar 31 03:26:11 2025
From: zihan.yan at hpe.com (Yan, Zihan)
Date: Mon, 31 Mar 2025 10:26:11 +0000
Subject: Missing GCMP-256 support in DPP client
Message-ID: <41191F65-F02B-434A-8F66-8986C594FE98@hpe.com>

Hi,
?
We?encountered a problem with connecting?a client (running wpa_supplicant)?to AP via DPP.
?
We want wpa_supplicant to?automatically?connect to the ssid via the network profile obtained from the DPP provision. When?AP SSID?s pairwise_cipher is CCMP-128, there is no problem with the connection. However,?when?AP SSID?s ?pairwise_cipher is GCMP-256, the following problem occurs?
?
?????????	Output from?Client?s?wpa_supplicant.log :
	1742375082.487211: wlo2: 2: 94:64:24:e4:a4:60 ssid='00_han_dpp' wpa_ie_len=0 	rsn_ie_len=30 caps=0x411 level=-18 freq=5240?
	1742375082.487272: wlo2:??? skip RSN IE - PTK cipher mismatch
	1742375082.487340: wlo2:??? skip - MFP Required but network not MFP Capable
?
The reason we found is that during DPP Provision, function?wpas_dpp_add_network()?assigns ssid->pairwise_cipher and ssid->group_cipher via?wpa_config_set_network_defaults()?with the default values?DEFAULT_PAIRWISE?and?DEFAULT_GROUP. Therefore, during subsequent network access scanning of the ssid, the pairwise_cipher provided by the AP (GCMP-256)?does not match the pairwise_cipher of the?client?(CCMP-128), resulting in a connection failure.
?
After I add GCMP-256 to the default value of pairwise_cipher, the connection is successful.?Here is the diff:
	+++ b/wpa_supplicant/dpp_supplicant.c
	@@ -1410,6 +1410,8 @@ static struct wpa_ssid * wpas_dpp_add_network(struct wpa_supplicant *wpa_s,
??????????????? return NULL;
??????? 	wpas_notify_network_added(wpa_s, ssid);
??????? 	wpa_config_set_network_defaults(ssid);
	+?????? ssid->pairwise_cipher |= WPA_CIPHER_GCMP_256;
	+?????? ssid->group_cipher |= WPA_CIPHER_GCMP_256;
???????	 ssid->disabled = 1;

Here are my questions:
1. Why the default value of ssid->pairwise_cipher for DPP network profile is set to CCMP or?CCMP+TKIP???Could GCMP_256 be added to the default value of DEFAULT_PAIRWISE and DEFAULT_GROUP?
2. Can we add the default value GCMP_256 to ssid->pairwise_cipher of the DPP network profile as the diff above?
?
wpa_supplicant.conf is configured as follows:
	ctrl_interface=/var/run/wpa_supplicant
	ctrl_interface_group=0
	#update_config=1
	p2p_disabled=1
	bss_expiration_age=250
	pmf=1
	sae_pwe=2
	dpp_config_processing=2
?
Thanks in advance for your help and looking forward to your reply!
?
Kind Regards,
Zihan
?
?



