Unable to authenticate wireless network after upgrade to 41.20241117.3

[drogo35]

Describe the bug

After upgrading my Aurora system from 41.20241112.1 to 41.20241117.3, my existing wireless connection failed to connect. The supplied password (stored for current user only) did not work. Deleting and re-creating the password did not resolve the issue. I rolled back to 41.20241112.1 and was prompted for wifi password, and it then connected. Allowing the system to upgrade to 41.20241117.3 saw the inability to connect to wifi return (the system prompts for a password, but still fails to connect).

What did you expect to happen?

I expected the new system to use the existing wireless profile or accept the password successfully.

Output of bootc status

Current booted image: ghcr.io/ublue-os/aurora-dx:stable
    Image version: 41.20241112.1 (2024-11-12 21:12:10 UTC)
    Image digest: sha256:f942d18322746e1135741bde40ef00d84c05b8ecbd39871e94260274b786b39c
Current rollback image: ghcr.io/ublue-os/aurora-dx:stable
    Image version: 41.20241117.3 (2024-11-17 15:52:27 UTC)
    Image digest: sha256:e78b70e68f068ad8e4331e636f4a488ff820fa5bbcdfa39a6643f0749414e790

Output of groups

drogo 35wheel lxd incus-admin docker libvirt

Extra information or context

The wifi connection is WPA2 Enterprise using free radius for authentication and with a certificate stored locally in ~/drogo35/documents/. The profile

[castrojo]

We need the hardware info, lshw -c network and paste in the appropriate wireless stanza, thanks!

[drogo35]

sudo lshw -c network
[sudo] password for drogo35:
*-network
description: Wireless interface
product: Wireless 8260
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:01:00.0
logical name: wlp1s0
version: 3a
serial: f2:3a:c6:b5:ce:55
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=iwlwifi driverversion=6.11.3-300.fc41.x86_64 firmware=36.ca7b901d.0 8000C-36.ucode ip=[IP address link removed for safety reasons] latency=0 link=yes multicast=yes wireless=IEEE 802.11
resources: irq:137 memory:e1200000-e1201fff

Thank you!

[Japsert123]

This might be related to this discussion: https://discussion.fedoraproject.org/t/unable-to-connect-to-wpa2-enterprise-after-upgrading-to-fedora-41/134889. There's already a bug filed for fedora: https://bugzilla.redhat.com/show_bug.cgi?id=2326839. Hope it gets fixed soon!

Edit: After rolling back to stable-20241110 I can connect to eduroam again.

[ash0x1b]

Having the same issue.

  *-network                 
       description: Wireless interface
       product: Alder Lake-P PCH CNVi WiFi
       vendor: Intel Corporation
       physical id: 14.3
       bus info: pci@0000:00:14.3
       logical name: wlp0s20f3
       version: 01
       serial: <MAC>
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=iwlwifi driverversion=6.11.3-300.fc41.x86_64 firmware=89.6b44fa0b.0 so-a0-gf-a0-89.uc ip=<IP> latency=0 link=yes multicast=yes wireless=IEEE 802.11
       resources: iomemory:600-5ff irq:16 memory:603d1d4000-603d1d7fff

Removing /etc/pki/tls/openssl.d/pkcs11-provider.conf and reboot fixed the issue.

[lethedata]

Definitely related to the bugzilla report @Japsert123 pointed out.

Two other ways I've found to let the connection go through are:
A) Enable pkcs11-module-load-behavior = early in the /etc/pki/tls/openssl.d/pkcs11-provider.conf
B) Enable legacy providers in /etc/ssl/openssl.cnf

---

Failing Connection:

Nov 19 06:18:18 bluefin wpa_supplicant[1876]: OpenSSL: EVP_DigestInit_ex failed: error:0308010C:digital envelope routines::unsupported
Nov 19 06:18:18 bluefin wpa_supplicant[1876]: EAP-MSCHAPV2: Failed to derive response

Network Info:

  *-network                 
       description: Wireless interface
       product: Wi-Fi 6E(802.11ax) AX210/AX1675* 2x2 [Typhoon Peak]
       vendor: Intel Corporation
       physical id: 0
       bus info: pci@0000:a6:00.0
       logical name: wlp166s0
       version: 1a
       serial: <MAC>
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=iwlwifi driverversion=6.11.3-300.fc41.x86_64 firmware=89.6b44fa0b.0 ty-a0-gf-a0-89.uc ip=[IP address link removed for safety reasons] latency=0 link=yes multicast=yes wireless=IEEE 802.11
       resources: irq:16 memory:7a200000-7a203fff

[ash0x1b]

Enabling pkcs11-module-load-behavior = early in /etc/pki/tls/openssl.d/pkcs11-provider.conf is probably the right way to do it.

I can confirm it works for our WPA2 Enterprise + Radius authentication.

[drogo35]

I just tested both removing pkcs11-provider.conf and setting the module load behavior value. Both allowed for a successful WiFi connection.

[castrojo]

If someone can confirm the working version we can pin it in the images:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/QA5NBNAOKCHXYM4BCXPLPB23FI6LQILN/#XBMSEYX5XJXNYZIAQEGCAKWT4YWEE2PE

[lethedata]

If someone can confirm the working version we can pin it in the images:

Working with or without a proper pkcs11-provider.conf file? I'm assuming you mean the former

[castrojo]

Yeah I think we want the one from before the change.

[castrojo]

Ok this is pinned in F41, let's see if it helps.

[lethedata]

Yeah I think we want the one from before the change.

Yeah, the rollback should fix things. Didn't include that config that enabled pkcs11 in OpenSSL.

[lethedata]

FYI: Per the upstream bug @Japsert123 posted (2326839), looks like they'll be updating the package to disable things until they figure out how it's going to be fixed.

https://bodhi.fedoraproject.org/updates/FEDORA-2024-fbf9ccda7b

[castrojo]

We'll hold the pin for one more week (since it's the holidays in the US).