WiFi and dmesg issues on Fedora 39 Silverblue

Ask Fedora
,
1

A couple of days ago I started having issues with WiFi and dmesg on Fedora 39 Silverblue. I use iwd for WiFi, and whenever I try to connect to the eduroam network it fails with failure code 23=IEEE8021X_FAILED:

[   60.078423] wlan0: authenticate with 78:bc:1a:c3:88:8e (local address=ac:7b:a1:b6:50:8a)
[   60.079212] wlan0: send auth to 78:bc:1a:c3:88:8e (try 1/3)
[   60.081688] wlan0: authenticated
[   60.084246] wlan0: associate with 78:bc:1a:c3:88:8e (try 1/3)
[   60.087556] wlan0: RX AssocResp from 78:bc:1a:c3:88:8e (capab=0x111 status=0 aid=34)
[   60.088970] wlan0: associated
[   60.158376] wlan0: Limiting TX power to 23 (23 - 0) dBm as advertised by 78:bc:1a:c3:88:8e
[   61.113913] wlan0: deauthenticating from 78:bc:1a:c3:88:8e by local choice (Reason: 23=IEEE8021X_FAILED)
[   61.611171] wlan0: authenticate with 78:bc:1a:c3:88:8e (local address=ac:7b:a1:b6:50:8a)
[   61.611909] wlan0: send auth to 78:bc:1a:c3:88:8e (try 1/3)
[   61.614241] wlan0: authenticated
[   61.615269] wlan0: associate with 78:bc:1a:c3:88:8e (try 1/3)
[   61.618343] wlan0: RX AssocResp from 78:bc:1a:c3:88:8e (capab=0x111 status=0 aid=34)
[   61.620566] wlan0: associated
[   61.694788] wlan0: Limiting TX power to 23 (23 - 0) dBm as advertised by 78:bc:1a:c3:88:8e
[   62.646162] wlan0: deauthenticating from 78:bc:1a:c3:88:8e by local choice (Reason: 23=IEEE8021X_FAILED)

Connecting to the unsecured guest network works without issues, and I’m able to connect to my WPA3 network at home too.

The second issue is with dmesg, where I’m unable to open the logs without using sudo:

michael@localhost:~$ dmesg
dmesg: read kernel buffer failed: Operation not permitted

I’m running the latest deployment of Fedora 39 Silverblue:

michael@localhost:~$ rpm-ostree status
State: idle
Deployments:
â—Ź fedora:fedora/39/x86_64/silverblue
                  Version: 39.20240214.0 (2024-02-14T01:05:03Z)
               BaseCommit: 6a3ffe043e670abf3ddddec7b37ee7fb075838ad42917fceb42a81e4c0859ecb
             GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C
          LayeredPackages: fira-code-fonts iwd libavcodec-freeworld
            LocalPackages: rpmfusion-free-release-39-0.2.noarch

  fedora:fedora/39/x86_64/silverblue
                  Version: 39.20240213.0 (2024-02-13T02:00:27Z)
               BaseCommit: 857a84221a550a9f0f91214d0f47d03dc6bc11f3a8169c294061e06ebc8189e8
             GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C
          LayeredPackages: fira-code-fonts iwd libavcodec-freeworld
            LocalPackages: rpmfusion-free-release-39-0.2.noarch

I think this issue appeared after a kernel update, and I was able to roll back several times to a working build. Unfortunately, I didn’t “freeze” the rpm-ostree build and make a note of which build was working and from which build onward the bug was introduced.

Has anyone else experienced this issue?

2

The dmesg issue is intentional based on Turn on SECURITY_DMESG_RESTRICT (ed5ba266) · Commits · cki-project / kernel-ark · GitLab

Looks like you can change the setting of kernel.dmesg_restrict sysctl kernel parameters to revert to the previous behavior. You should also be able to use journalctl -k

2 Likes
3

Thanks! Yup, journalctl -k works. I think the dmesg issue is unrelated to the WiFi issue, it just happened to coincide with it which made me think there’s a connection.

Meanwhile, I’ve enabled verbose TLS debugging for iwd and I get the following error in journalctl when I try to connect to eduroam:

Feb 14 14:16:50 localhost iwd[5093]: TTLS: tls_tx_handshake:1244 Sending a TLS_CLIENT_HELLO of 140 bytes
Feb 14 14:16:50 localhost iwd[5093]: TTLS: l_tls_start:3610 New state TLS_HANDSHAKE_WAIT_HELLO
Feb 14 14:16:50 localhost iwd[5093]: TTLS: tls_handle_handshake:3074 Handling a TLS_SERVER_HELLO of 45 bytes
Feb 14 14:16:50 localhost iwd[5093]: TTLS: tls_handle_server_hello:2419 Negotiated TLS 1.2
Feb 14 14:16:50 localhost iwd[5093]: TTLS: tls_handle_server_hello:2455 Negotiated TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Feb 14 14:16:50 localhost iwd[5093]: TTLS: tls_handle_server_hello:2466 Negotiated CompressionMethod.null
Feb 14 14:16:50 localhost iwd[5093]: TTLS: tls_handle_server_hello:2492 New state TLS_HANDSHAKE_WAIT_CERTIFICATE
Feb 14 14:16:50 localhost iwd[5093]: TTLS: tls_handle_handshake:3074 Handling a TLS_CERTIFICATE of 2126 bytes
Feb 14 14:16:50 localhost iwd[5093]: TTLS: tls_handle_certificate:2562 Peer certchain written to /tmp/iwd-tls-debug-server-cert.pem
Feb 14 14:16:50 localhost iwd[5093]: TTLS: tls_handle_certificate:2673 Disconnect desc=internal_error local-desc=close_notify reason=Can't l_key_get_info for peer public key
Feb 14 14:16:50 localhost iwd[5093]: TTLS: tls_send_alert:1175 Sending a Fatal Alert: internal_error
Feb 14 14:16:50 localhost iwd[5093]: TTLS: tls_reset_handshake:195 New state TLS_HANDSHAKE_WAIT_START
Feb 14 14:16:50 localhost iwd[5093]: TTLS: Tunnel has disconnected with alert: internal_error
Feb 14 14:16:51 localhost iwd[5093]: EAP completed with eapFail
Feb 14 14:16:51 localhost iwd[5093]: TTLS: tls_reset_handshake:195 New state TLS_HANDSHAKE_WAIT_START
Feb 14 14:16:51 localhost iwd[5093]: TTLS: tls_reset_handshake:195 New state TLS_HANDSHAKE_WAIT_START
Feb 14 14:16:51 localhost iwd[5093]: 4-Way handshake failed for ifindex: 6, reason: 23

I found a post over at Arch forums where someone else had gotten the same reason=Can't l_key_get_info for peer public key error: iwd, eduroam, bad_certificate error / Networking, Server, and Protection / Arch Linux Forums

That topic linked further to this topic about the deprecation of SHA-1 in the kernel: SHA1 deprecation in Kernel's crypto API? / Kernel & Hardware / Arch Linux Forums

It looks like this issue is caused by that deprecation. I haven’t been able to confirm whether one of the certificates that are used at my uni uses SHA-1, but I suspect that’s the case given that the person who experienced the same issue as me was able to connect to their eduroam again after reverting the change.