I upgraded this morning to the latest version of wpa_supplicant (1:2.11-1.fc40) and after rebooting the machine, the internet wasn't working. I tried to edit some configuration but no luck, so I decided to downgrade the package to the previous working version 1:2.10-10.fc40 and it's working again. I don't have logs but I could see in journalctl the first message was about trying to create p2p device from wireless one with no success. The WiFi icon was loading without being connected and suddenly the device became disabled. Reproducible: Didn't try Steps to Reproduce: 1. sudo dnf upgrade --refresh Actual Results: The internet connection couldn't be stablished over wireless. Expected Results: A successful internet connection to the AP.
Exactly the same thing happens to me. fc40.x86_64 Fedora 40 Broadcom BCM4360
I can confirm broadcom device is also broken by this update on my aarch64 system running Fedora 40. (Fedora Asahi Remix on MacBook Air M1). I think archlinux (x86_64) tried to fix this by re-applying a patch called "add extra-ies only if allowed by driver" Of course I don't even understand what any of that means, so it might very well be completely unrelated.
A fix for a kernel NULL ptr dereference in the brcmfmac driver is sent as https://lore.kernel.org/asahi/20240803-brcmfmac_pmksa_del_ssid-v1-1-4e85f19135e1@jannau.net/T/#u This will be hopefully in the next stable kernel. An update for the Fedora-Asahi-Remix kernel with this fix will be built as soon as possible. This should allow configuring the as WPA2 (if possible) to allow wlan connectivity with wpa_supplicant 2.11. WPA3 / SAE Offload is unfortunately still broken with this fix. This seems to be a difference between wpa_supplicant 2.10 + SAE Offload patches and wpa_supplicant 2.11 with merged SAE Offload.
BCM43602 802.11ac Wireless LAN SoC on a MBP 12,1 was impacted. I needed to connect to wired networking and downgrade. Begin time : Sat 03 Aug 2024 02:45:01 PM MDT Begin rpmdb : ff7f3d8ac292e23f7e044ab492474ac26ac8ba8c59cab2177c7047456276c649 End time : Sat 03 Aug 2024 02:45:04 PM MDT (3 seconds) End rpmdb : 24d91113d752a2593f2aefe8b15045b8e44deaf46cb03a33aa5b0fd7b614f5f8 User : Jon <jon> Return-Code : Success Releasever : 40 Command Line : downgrade wpa_supplicant Comment : Packages Altered: Downgrade wpa_supplicant-1:2.10-10.fc40.x86_64 @fedora Downgraded wpa_supplicant-1:2.11-1.fc40.x86_64 @@System
A fix by reverting a single upstream commit is available at https://src.fedoraproject.org/rpms/wpa_supplicant/pull-request/25 Reported upstream in http://lists.infradead.org/pipermail/hostap/2024-August/042893.html
Instead of downgrade to wpa_supplicant 2.10 disabling Offload works add well. Add "brcmfmac.feature_disable=0x82000" to the kernel command line either at the bootloader or via grubby. See https://iwd.wiki.kernel.org/offloading for reference.
(In reply to Janne Grunau from comment #6) > Instead of downgrade to wpa_supplicant 2.10 disabling Offload works add > well. Add "brcmfmac.feature_disable=0x82000" to the kernel command line > either at the bootloader or via grubby. See > https://iwd.wiki.kernel.org/offloading for reference. This is not work for a configurations like mine with tp-link Archer T6E(ac1300 wireless dual band pci express adapter) aka BCM4360 The driver in use is broadcom hybrid wireless driver 'wl' So obviously I'll stick with wpa_supplicant 2.10-10 on Fedora 40
Seeing a issue using wpa-eap with a pkcs11 private key.Downgrade to 2.10 and it works again. <info> [1722934597.2072] device (wlp1s0): Activation: (wifi) connection 'Wireless' has security, and secrets exist. No new secrets needed. Is this issue related or something different?
I had the same problem. No wi-fi AP could be found. Once i downgraded to 2.10 everything start working again
Mine is a different issue opened a new bug here. https://bugzilla.redhat.com/show_bug.cgi?id=2303165
FEDORA-2024-82fdfeff80 (wpa_supplicant-2.11-2.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-82fdfeff80
(In reply to Fedora Update System from comment #11) > FEDORA-2024-82fdfeff80 (wpa_supplicant-2.11-2.fc40) has been submitted as an > update to Fedora 40. > https://bodhi.fedoraproject.org/updates/FEDORA-2024-82fdfeff80 Unfortunately, there is no change for me with 2.11-2 I am compelled to return again to 2.10-10 Тhis is my log : 19:12:45 wpa_supplicant: wlp5s0: CTRL-EVENT-SCAN-FAILED ret=-22 19:11:33 NetworkManager: <info> [1722960693.9828] device (wlp5s0): supplicant interface state: disconnected -> inactive 19:11:33 wpa_supplicant: wlp5s0: CTRL-EVENT-SCAN-FAILED ret=-22 19:11:33 NetworkManager: <info> [1722960693.6809] device (wlp5s0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed') 19:11:33 wpa_supplicant: wlp5s0: CTRL-EVENT-DSCP-POLICY clear_all 19:11:33 NetworkManager: <info> [1722960693.6805] device (wlp5s0): state change: config -> failed (reason 'ssid-not-found', sys-iface-state: 'managed') 19:11:32 wpa_supplicant: wlp5s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 19:11:07 NetworkManager: <info> [1722960667.9492] device (wlp5s0): Activation: (wifi) connection 'WF-AP-5GHz' has security, and secrets exist. No new secrets needed. 19:11:07 NetworkManager: <info> [1722960667.9491] device (wlp5s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') 19:11:07 NetworkManager: <info> [1722960667.9489] device (wlp5s0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 'managed') 19:11:07 NetworkManager: <info> [1722960667.9485] device (wlp5s0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed') 19:11:07 NetworkManager: <info> [1722960667.9485] device (wlp5s0): Activation: (wifi) access point 'WF-AP-5GHz' has security, but secrets are required. 19:11:07 NetworkManager: <info> [1722960667.9483] device (wlp5s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') 19:11:07 NetworkManager: <info> [1722960667.9476] device (wlp5s0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') 19:11:07 NetworkManager: <info> [1722960667.9475] device (wlp5s0): Activation: starting connection 'WF-AP-5GHz' (2e7425e1-c3ef-426d-997e-497c74e11714) 19:11:04 wpa_supplicant: wlp5s0: CTRL-EVENT-SCAN-FAILED ret=-22 19:10:22 NetworkManager: <info> [1722960622.1409] device (wlp5s0): state change: unavailable -> disconnected (reason 'supplicant-available', sys-iface-state: 'managed') 19:10:22 NetworkManager: <info> [1722960622.1409] device (wlp5s0): supplicant interface state: internal-starting -> disconnected 19:10:22 NetworkManager: <info> [1722960622.0250] device (wlp5s0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external') 19:10:22 NetworkManager: <info> [1722960622.0249] manager: (wlp5s0): new 802.11 Wi-Fi device (/org/freedesktop/NetworkManager/Devices/2) 19:10:22 NetworkManager: <info> [1722960622.0246] device (wlp5s0): driver supports Access Point (AP) mode 19:10:22 NetworkManager: <info> [1722960622.0130] rfkill0: found Wi-Fi radio killswitch (at /sys/devices/pci0000:00/0000:00:01.2/0000:02:00.2/0000:03:07.0/0000:05:00.0/ieee80211/phy0/rfkill0) (driver wl) 19:10:21 NetworkManager: <info> [1722960621.9498] Read config: /etc/NetworkManager/NetworkManager.conf (lib: 20-connectivity-fedora.conf, 22-wifi-mac-addr.conf, 90-broadcom-wl.conf) 19:10:20 kernel: wl 0000:05:00.0 wlp5s0: renamed from eth0 19:10:20 kernel: wl 0000:05:00.0 wlp5s0: renamed from eth0 19:10:20 kernel: wl 0000:05:00.0: enabling device (0000 -> 0002) 19:10:20 kernel: wl_module_init+0x17/0xa0 [wl] 19:10:20 kernel: wl_module_init+0x17/0xa0 [wl] 19:10:20 kernel: ? __UNIQUE_ID_vermagic434+0x523e3f547ebb/0x523e3f547ebb [wl] 19:10:20 kernel: getvar+0x20/0x70 [wl] 19:10:20 kernel: Modules linked in: ... wl(POE+) ...
(In reply to Fedora Update System from comment #11) > FEDORA-2024-82fdfeff80 (wpa_supplicant-2.11-2.fc40) has been submitted as an > update to Fedora 40. > https://bodhi.fedoraproject.org/updates/FEDORA-2024-82fdfeff80 And for greater clarity, my log with wpa_supplicant 2.10-10 19:31:38 NetworkManager: <info> [1722961898.6287] dhcp6 (wlp5s0): state changed new lease 19:31:38 avahi-daemon: Withdrawing address record for fe80::9f15:59a1:bf58:5677 on wlp5s0. 19:31:38 NetworkManager: <info> [1722961898.6257] dhcp6 (wlp5s0): activation: beginning transaction (timeout in 45 seconds) 19:31:33 systemd-resolve: wlp5s0: Bus client set DNS server list to: yyy.yyy.yyy.yyy 19:31:33 systemd-resolve: wlp5s0: Bus client set default route setting: yes 19:31:33 avahi-daemon: Registering new address record for xxx.xxx.xxx.xxx on wlp5s0.IPv4. 19:31:33 avahi-daemon: Registering new address record for xxx.xxx.xxx.xxx on wlp5s0.IPv4. 19:31:33 avahi-daemon: New relevant interface wlp5s0.IPv4 for mDNS. 19:31:33 systemd-resolve: wlp5s0: Bus client set search domain list to: net-provider 19:31:33 avahi-daemon: Joining mDNS multicast group on interface wlp5s0.IPv4 with address xxx.xxx.xxx.xxx 19:31:33 NetworkManager: <info> [1722961893.5293] policy: set 'WF-AP-5GHz' (wlp5s0) as default for IPv4 routing and DNS 19:31:33 NetworkManager: <info> [1722961893.5293] policy: set 'WF-AP-5GHz' (wlp5s0) as default for IPv4 routing and DNS 19:31:33 NetworkManager: <info> [1722961893.5290] dhcp4 (wlp5s0): state changed new lease, address=xxx.xxx.xxx.xxx 19:31:33 NetworkManager: <info> [1722961893.3748] dhcp4 (wlp5s0): state changed new lease, address=xxx.xxx.xxx.xxx, acd pending 19:31:33 avahi-daemon: Registering new address record for fe80::9f15:59a1:bf58:5677 on wlp5s0.*. 19:31:33 avahi-daemon: Registering new address record for fe80::9f15:59a1:bf58:5677 on wlp5s0.*. 19:31:33 avahi-daemon: New relevant interface wlp5s0.IPv6 for mDNS. 19:31:33 avahi-daemon: Joining mDNS multicast group on interface wlp5s0.IPv6 with address fe80::9f15:59a1:bf58:5677. 19:31:33 NetworkManager: <info> [1722961893.2943] dhcp4 (wlp5s0): activation: beginning transaction (timeout in 45 seconds) 19:31:33 NetworkManager: <info> [1722961893.2943] dhcp4 (wlp5s0): activation: beginning transaction (timeout in 45 seconds) 19:31:33 NetworkManager: <info> [1722961893.2940] device (wlp5s0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed') 19:31:33 NetworkManager: <info> [1722961893.2583] device (wlp5s0): Activation: (wifi) Stage 2 of 5 (Device Configure) successful. Connected to wireless network "WF-AP-5GHz" 19:31:33 NetworkManager: <info> [1722961893.2583] device (wlp5s0): supplicant interface state: associating -> completed 19:31:33 wpa_supplicant: wlp5s0: CTRL-EVENT-CONNECTED - Connection to ac:84:c6:95:4d:ed completed [id=0 id_str=] 19:31:33 wpa_supplicant: wlp5s0: CTRL-EVENT-CONNECTED - Connection to ac:84:c6:95:4d:ed completed [id=0 id_str=] 19:31:33 wpa_supplicant: wlp5s0: WPA: Key negotiation completed with ac:84:c6:95:4d:ed [PTK=CCMP GTK=TKIP] 19:31:33 wpa_supplicant: wlp5s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 19:31:33 wpa_supplicant: wlp5s0: Associated with ac:84:c6:95:4d:ed 19:31:33 NetworkManager: <info> [1722961893.1697] device (wlp5s0): supplicant interface state: disconnected -> associating 19:31:33 wpa_supplicant: wlp5s0: Trying to associate with ac:84:c6:95:4d:ed (SSID='WF-AP-5GHz' freq=5220 MHz) 19:31:33 wpa_supplicant: wlp5s0: Trying to associate with ac:84:c6:95:4d:ed (SSID='WF-AP-5GHz' freq=5220 MHz) 19:31:33 wpa_supplicant: wlp5s0: WPS-CANCEL 19:31:33 NetworkManager: <info> [1722961893.1592] device (wlp5s0): Activation: (wifi) connection 'WF-AP-5GHz' has security, and secrets exist. No new secrets needed. 19:31:33 NetworkManager: <info> [1722961893.1590] device (wlp5s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') 19:31:33 wpa_supplicant: wlp5s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1 19:31:33 NetworkManager: <info> [1722961893.1589] device (wlp5s0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 'managed') 19:31:33 NetworkManager: <info> [1722961893.1584] sup-iface[95955dfa455bbbfd,0,wlp5s0]: wps: type pbc start... 19:31:33 NetworkManager: <info> [1722961893.1584] device (wlp5s0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed') 19:31:33 NetworkManager: <info> [1722961893.1584] device (wlp5s0): Activation: (wifi) access point 'WF-AP-5GHz' has security, but secrets are required. 19:31:33 NetworkManager: <info> [1722961893.1582] device (wlp5s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') 19:31:33 NetworkManager: <info> [1722961893.1579] device (wlp5s0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') 19:31:33 NetworkManager: <info> [1722961893.1579] device (wlp5s0): Activation: starting connection 'WF-AP-5GHz' (2e7425e1-c3ef-426d-997e-497c74e11313) 19:31:31 NetworkManager: <info> [1722961891.1990] device (wlp5s0): state change: unavailable -> disconnected (reason 'supplicant-available', sys-iface-state: 'managed') 19:31:31 NetworkManager: <info> [1722961891.1990] device (wlp5s0): supplicant interface state: internal-starting -> disconnected 19:31:30 NetworkManager: <info> [1722961890.9370] device (wlp5s0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external') 19:31:30 NetworkManager: <info> [1722961890.9369] manager: (wlp5s0): new 802.11 Wi-Fi device (/org/freedesktop/NetworkManager/Devices/2) 19:31:30 NetworkManager: <info> [1722961890.9366] device (wlp5s0): driver supports Access Point (AP) mode 19:31:30 NetworkManager: <info> [1722961890.9234] rfkill0: found Wi-Fi radio killswitch (at /sys/devices/pci0000:00/0000:00:01.2/0000:02:00.2/0000:03:07.0/0000:05:00.0/ieee80211/phy0/rfkill0) (driver wl) 19:31:30 NetworkManager: <info> [1722961890.8692] Read config: /etc/NetworkManager/NetworkManager.conf (lib: 20-connectivity-fedora.conf, 22-wifi-mac-addr.conf, 90-broadcom-wl.conf) 19:31:28 kernel: wl 0000:05:00.0 wlp5s0: renamed from eth0 19:31:28 kernel: wl 0000:05:00.0 wlp5s0: renamed from eth0 19:31:28 kernel: wl 0000:05:00.0: enabling device (0000 -> 0002) 19:31:28 kernel: wl_module_init+0x17/0xa0 [wl] 19:31:28 kernel: wl_module_init+0x17/0xa0 [wl] 19:31:28 kernel: ? __UNIQUE_ID_vermagic434+0x4412bf5a7ebb/0x4412bf5a7ebb [wl] 19:31:28 kernel: getvar+0x20/0x70 [wl] 19:31:28 kernel: Modules linked in: ... wl(POE+) ...
I forgot that wpa_supplicant 2.11 will hit a NULL pointer dereference in the upstream / Fedora kernel. A fix was submitted on 3rd of August at https://lore.kernel.org/linux-wireless/20240803-brcmfmac_pmksa_del_ssid-v1-1-4e85f19135e1@jannau.net/ The change is included in the Fedora Asahi remix kernel so wpa_supplicant-2.11-2 works on Fedora Asahi remix systems.
(In reply to Janne Grunau from comment #14) > I forgot that wpa_supplicant 2.11 will hit a NULL pointer dereference in the > upstream / Fedora kernel. A fix was submitted on 3rd of August at > https://lore.kernel.org/linux-wireless/20240803-brcmfmac_pmksa_del_ssid-v1-1- > 4e85f19135e1/ > > The change is included in the Fedora Asahi remix kernel so > wpa_supplicant-2.11-2 works on Fedora Asahi remix systems. Janne, could you please confirm that wpa_supplicant-2.11-2.fc40 would work with brcmfmac on non-Asahi kernels? It's about to go to stable.
The following is working for me with the updated package: $ uname -r 6.9.12-200.fc40.x86_64 $ rpm -q wpa_supplicant wpa_supplicant-2.11-2.fc40.x86_64 $ lshw -C network WARNING: you should run this program as super-user. *-network description: Wireless interface product: BCM43602 802.11ac Wireless LAN SoC vendor: Broadcom Inc. and subsidiaries physical id: 0 bus info: pci@0000:03:00.0 logical name: wlp3s0 version: 01 serial: XXX width: 64 bits clock: 33MHz capabilities: bus_master cap_list ethernet physical wireless configuration: broadcast=yes driver=brcmfmac driverversion=7.35.177.61 firmware=01-ea662a8c ip=XXX latency=0 multicast=yes wireless=IEEE 802.11 resources: irq:80 memory:c1400000-c1407fff memory:c1000000-c13fffff
wpa_supplicant-2.11-2 is an improvement on non-asahi brcmfmac systems. Connecting to WPA2/WPA3 will work again. On disconnect it will hit the NULL pointer dereference in the kernel (fixed by https://lore.kernel.org/linux-wireless/20240803-brcmfmac_pmksa_del_ssid-v1-1-4e85f19135e1@jannau.net/). For stationary system this is probably not noticeable but systems switching between wireless networks will need to be rebooted. This bug is already triggered wpa_supplicant-2.11-1 after the initial connection to a WPA2/WPA3 network time outs.
FEDORA-2024-82fdfeff80 (wpa_supplicant-2.11-2.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
Can anyone affected please open a new bug about the NULL pointer dereference bug and reference it here, so that we can track it and poke wpa_supplicant maintainers to hotfix it? Thanks.
Issue still persists in wpa_supplicant-2.11-2.fc40 on fedora 40 Aug 08 14:22:28 fedora systemd[1]: Started NetworkManager.service - Network Manager. Aug 08 14:22:28 fedora NetworkManager[1075]: <info> [1723116148.8632] device (lo): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'external') Aug 08 14:22:28 fedora NetworkManager[1075]: <info> [1723116148.8682] modem-manager: ModemManager available Aug 08 14:22:28 fedora NetworkManager[1075]: <info> [1723116148.8708] device (lo): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'external') Aug 08 14:22:28 fedora NetworkManager[1075]: <info> [1723116148.8712] device (lo): state change: secondaries -> activated (reason 'none', sys-iface-state: 'external') Aug 08 14:22:28 fedora NetworkManager[1075]: <info> [1723116148.8725] device (lo): Activation: successful, device activated. Aug 08 14:22:29 fedora NetworkManager[1075]: <info> [1723116149.0958] device (wlo1): supplicant interface state: internal-starting -> disconnected Aug 08 14:22:29 fedora NetworkManager[1075]: <info> [1723116149.0960] device (wlo1): state change: unavailable -> disconnected (reason 'supplicant-available', sys-if> Aug 08 14:22:34 fedora NetworkManager[1075]: <info> [1723116154.7786] manager: startup complete Aug 08 14:22:43 fedora NetworkManager[1075]: <info> [1723116163.8793] agent-manager: agent[e6b76bbfa45e0607,:1.37/org.gnome.Shell.NetworkAgent/42]: agent registered Aug 08 14:22:28 fedora systemd[1]: Starting wpa_supplicant.service - WPA supplicant... Aug 08 14:22:29 fedora wpa_supplicant[1109]: Successfully initialized wpa_supplicant Aug 08 14:22:29 fedora systemd[1]: Started wpa_supplicant.service - WPA supplicant. Aug 08 14:22:29 fedora wpa_supplicant[1109]: dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.Interface.P2PDevice dbus_property=P2PDeviceConfig ge> Aug 08 14:22:29 fedora wpa_supplicant[1109]: wlo1: CTRL-EVENT-SCAN-FAILED ret=-22 Aug 08 14:22:32 fedora wpa_supplicant[1109]: wlo1: CTRL-EVENT-SCAN-FAILED ret=-22 Aug 08 14:22:37 fedora wpa_supplicant[1109]: wlo1: CTRL-EVENT-SCAN-FAILED ret=-22 Aug 08 14:22:44 fedora wpa_supplicant[1109]: wlo1: CTRL-EVENT-SCAN-FAILED ret=-22 Aug 08 14:22:54 fedora wpa_supplicant[1109]: wlo1: CTRL-EVENT-SCAN-FAILED ret=-22
jforbes says the kernel-side fix for this is queued for the Fedora 6.10.4 build, which should happen soon.
This fix (wpa_supplicant-2.11-2.fc40) is not working for the non-free broadcom-wl drivers on x86_64 systems. Should we expect a fix in connection to broadcom-wl as well?
This version (wpa_supplicant-2.11-2.fc40.x86_64) is writing debug lines to the log every 3 seconds: Aug 09 21:02:09 fedora wpa_supplicant[1166]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-62 noise=9999 txrate=780000 Aug 09 21:02:12 fedora wpa_supplicant[1166]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-62 noise=9999 txrate=780000 Aug 09 21:02:15 fedora wpa_supplicant[1166]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-62 noise=9999 txrate=780000 Aug 09 21:02:18 fedora wpa_supplicant[1166]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-63 noise=9999 txrate=780000 Aug 09 21:02:21 fedora wpa_supplicant[1166]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-63 noise=9999 txrate=780000 Aug 09 21:02:24 fedora wpa_supplicant[1166]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-63 noise=9999 txrate=780000 Aug 09 21:02:27 fedora wpa_supplicant[1166]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-63 noise=9999 txrate=780000 Aug 09 21:02:30 fedora wpa_supplicant[1166]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-54 noise=9999 txrate=780000 Aug 09 21:02:33 fedora wpa_supplicant[1166]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-63 noise=9999 txrate=780000 Aug 09 21:02:36 fedora wpa_supplicant[1166]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-54 noise=9999 txrate=780000 Aug 09 21:02:39 fedora wpa_supplicant[1166]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-63 noise=9999 txrate=780000 Aug 09 21:02:42 fedora wpa_supplicant[1166]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-53 noise=9999 txrate=780000 Aug 09 21:02:45 fedora wpa_supplicant[1166]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-51 noise=9999 txrate=780000 Aug 09 21:02:48 fedora wpa_supplicant[1166]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-60 noise=9999 txrate=780000 Aug 09 21:02:51 fedora wpa_supplicant[1166]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-51 noise=9999 txrate=780000
(In reply to Mike B. from comment #22) > This fix (wpa_supplicant-2.11-2.fc40) is not working for the non-free > broadcom-wl drivers on x86_64 systems. Should we expect a fix in connection > to broadcom-wl as well? For now broadcom 'wl' driver and wpa_supplicant 2.11-X are incompatible again. The man who can surely make it compatible is mr.D.Caratti, аt least he has done it more than once so far. If he has nоt done so yet, there is probably a reasons beyond our understanding. For now, the solution is : 1) 2.10-10 dnf version lock 2) Using alternatives
(In reply to Mike B. from comment #22) > This fix (wpa_supplicant-2.11-2.fc40) is not working for the non-free > broadcom-wl drivers on x86_64 systems. Should we expect a fix in connection > to broadcom-wl as well? You'll probably need to get that from where ever broadcom-wl comes from if it's an issue with the driver.
It might make the most sense to open a new bug report that is specific to the broadcom-wl driver. This bug is focused on brcmfmac. https://bugzilla.redhat.com/show_bug.cgi?id=2303165 is focused on WPA-EAP and a fix for that is in testing.
> It might make the most sense to open a new bug report that is specific to > the broadcom-wl driver. I believe that driver is out of tree and not shipped in Fedora. Hence my comment in #25
(In reply to Peter Robinson from comment #25) > > You'll probably need to get that from where ever broadcom-wl comes from if > it's an issue with the driver. Fair enough, thanks for the answer.
O.K. I know I'm not exactly in the right place but because I just want to be honest I want to say that wpa_supplicant(at least with ver.2.11-3) works with broadcom 'wl' driver. What and how it can be done... 1) Install wpa_supplicant ver. 2.11-3 2) sudo iw dev wlp4s0 scan and if there is nothing : sudo ifconfig wlp4s0 up 3) sudo wpa_passphrase WF-AP-5GHz (password) >> /etc/wpa_supplicant/wpa_supplicant.conf 4) sudo systemctl restart NetworkManager, or to be sure reboot 4) sudo iw dev wlp4s0 scan After each reboot or shutdown run : sudo iw dev wlp4s0 scan, but this can be automated. That's it. That's how it works for me. But inexplicable to me why, however sudo wpa_supplicant -D wl -i wlp4s0 -c/etc/wpa_supplicant/wpa_supplicant.conf tells to me : Successfully initialized wpa_supplicant wlp4s0: Unsupported driver 'wl'
I can confirm this: I get log entries like wpa_supplicant[1433]: wlp2s0: CTRL-EVENT-SCAN-FAILED ret=-22 until it enter sudo iw dev wlp2s0 scan Then the full thing kicks in, I don't need the previous steps. (1-4 above)
*** Bug 2304817 has been marked as a duplicate of this bug. ***
I'm facing issues particularly discovering and connecting to my Android hotspot with both versions of wpa_supplicant 2.10 and 2.11-3 I'm on Asahi Fedora 40
(In reply to assamhaa from comment #32) > I'm facing issues particularly discovering and connecting to my Android > hotspot with both versions of wpa_supplicant 2.10 and 2.11-3 > > I'm on Asahi Fedora 40 Unrelated problem, please report it to Asahi
(In reply to Serge Droz from comment #30) > I can confirm this: > > I get log entries like > > wpa_supplicant[1433]: wlp2s0: CTRL-EVENT-SCAN-FAILED ret=-22 > > until it enter > > sudo iw dev wlp2s0 scan > > Then the full thing kicks in, I don't need the previous steps. (1-4 above) Sorry for replying at not exactly the right place. I can also confirm that on a Macbook Air (early 2015) sudo iw dev [device] scan restores wifi connection with wpa_supplicant (2.11-3) and broadcom-wl (6.30.223.271-23). However, in my case, wifi drops again (not showing anything available) after suspension (sudo systemctl suspend or just wait for idling) and waking up. Remove and reload the kernel module (sudo modprobe -r wl && sudo modprobe wl), on the other hand, somehow makes wifi to keep working despite suspension until a reboot. I tried to compare if journalctl -u wpa_supplicant and dmesg show anything different between the first and second approach, but the only lines that were different to me were the following two lines that only appear when I remove and reload wl: Aug 18 23:15:57 fedora wpa_supplicant[1851]: nl80211: deinit ifname=wlp3s0 disabled_11b_rates=0 Aug 18 23:15:57 fedora wpa_supplicant[1851]: ioctl[SIOCSIWENCODEEXT]: Invalid argument I lack the expertise to tell if this information is useful or not, and I apologize if it isn't. Thank everyone for looking into this!
(In reply to Yen-Chung Chen from comment #34) > (In reply to Serge Droz from comment #30) > > I can confirm this: > > > > I get log entries like > > > > wpa_supplicant[1433]: wlp2s0: CTRL-EVENT-SCAN-FAILED ret=-22 > > > > until it enter > > > > sudo iw dev wlp2s0 scan > > > > Then the full thing kicks in, I don't need the previous steps. (1-4 above) > > Sorry for replying at not exactly the right place. I can also confirm that > on a Macbook Air (early 2015) sudo iw dev [device] scan restores wifi > connection with wpa_supplicant (2.11-3) and broadcom-wl (6.30.223.271-23). > However, in my case, wifi drops again (not showing anything available) after > suspension (sudo systemctl suspend or just wait for idling) and waking up. > > Remove and reload the kernel module (sudo modprobe -r wl && sudo modprobe > wl), on the other hand, somehow makes wifi to keep working despite > suspension until a reboot. > > I tried to compare if journalctl -u wpa_supplicant and dmesg show anything > different between the first and second approach, but the only lines that > were different to me were the following two lines that only appear when I > remove and reload wl: > > Aug 18 23:15:57 fedora wpa_supplicant[1851]: nl80211: deinit ifname=wlp3s0 > disabled_11b_rates=0 > Aug 18 23:15:57 fedora wpa_supplicant[1851]: ioctl[SIOCSIWENCODEEXT]: > Invalid argument > > I lack the expertise to tell if this information is useful or not, and I > apologize if it isn't. Thank everyone for looking into this! Apply the procedure described here : https://forums.fedoraforum.org/showthread.php?333082-after-last-update-the-wifi-stopped-displaying-or-connecting-to-wireless-networks&p=1886059#post1886059 eliminates the unwanted behavior you wrote. Max. 30 seconds after exiting suspend, the connection resumes automatically. This is only work around not "solution".
Hello, Sorry for maybe not answering in exactly the right place too, and probably being wrong about that issue, but wouldn't it be worth to give a try to the patch applied by the maintainer of the archlinux wpa_supplicant package? https://gitlab.archlinux.org/archlinux/packaging/packages/wpa_supplicant/-/blob/main/0007-nl80211-add-extra-ies-only-if-allowed-by-driver.patch?ref_type=heads It seems to take care of these old drivers for old wireless devices like broadcom-wl which don't support last new functionalities but still provide good service in everyday use in not so old machines. Cordially, -- NVieville
(In reply to nicolas.vieville from comment #36) > Hello, > > Sorry for maybe not answering in exactly the right place too, and probably > being wrong about that issue, but wouldn't it be worth to give a try to the > patch applied by the maintainer of the archlinux wpa_supplicant package? > > https://gitlab.archlinux.org/archlinux/packaging/packages/wpa_supplicant/-/ > blob/main/0007-nl80211-add-extra-ies-only-if-allowed-by-driver. > patch?ref_type=heads > > It seems to take care of these old drivers for old wireless devices like > broadcom-wl which don't support last new functionalities but still > provide good service in everyday use in not so old machines. > > Cordially, > > > -- > NVieville That's it, no workarounds seem to be needed anymore. I recently built with this patch and can confirm that for me everything works. With suspend/resume there are no problems either.
That patch is from two years ago...https://patchwork.ozlabs.org/project/hostap/patch/20220130192200.10883-1-mail@david-bauer.net/#2830567 . It doesn't look like upstream ever merged it. We don't really love carrying patches downstream forever, and it seems like we didn't need this one before 2.11 (I've just checked, and it doesn't look like we had it before but dropped it as part of the 2.11 bump, or anything). I'm not enough of a subject matter expert to know much beyond that, though.
(In reply to Adam Williamson from comment #38) > That patch is from two years > ago...https://patchwork.ozlabs.org/project/hostap/patch/20220130192200.10883- > 1-mail/#2830567 . It doesn't look like upstream ever merged > it. We don't really love carrying patches downstream forever, and it seems > like we didn't need this one before 2.11 (I've just checked, and it doesn't > look like we had it before but dropped it as part of the 2.11 bump, or > anything). I'm not enough of a subject matter expert to know much beyond > that, though. I used wpa_supplicant 2.11-3 source code (https://kojipkgs.fedoraproject.org//packages/wpa_supplicant/2.11/3.fc40/src/wpa_supplicant-2.11-3.fc40.src.rpm) Before modifying the source I made sure that the proposed changes in wpa_supplicant/src/drivers/driver.h <- line 2357+ wpa_supplicant/src/drivers/driver_nl80211_capa.c <- line 976+ wpa_supplicant/src/drivers/driver_nl80211_scan.c <- 221+ were not available. The decisions are yours.
Created attachment 2044568 [details] Enable-extra-ies-only-if-allowed-by-driver Confirming that the patch also works on my old intel macbook (MacBookAir6,2) with the wl driver. I have added the attached patch that works on top of the f40 branch of wpa_supplicant [1] and works for me locally. It would be hugely helpful to have this added so I don't need to maintain a patch on the side. It also appears that Debian and Arch carry this patch so far as I can tell. But to your point, I am not sure why this wasn't landed upstream. What would the best approach be to getting something like this added in to help keep these older machines working? As an aside, I tried to go the PR approach, but could not get the source to push into the fork I made [2] since I am not in packagers group (I think). Is there a temp group for new contributors or is this approach preferred? [1]: https://src.fedoraproject.org/rpms/wpa_supplicant/tree/f40 [2]: https://src.fedoraproject.org/fork/mulderje/rpms/wpa_supplicant
Adding a few links for context on where I have found other distributions to be carrying the above patch. Hoping to help save others some searches, and that it helps with the decision making process. For what it is worth, it doesn't look like Gentoo is carrying the patch. Alpine: https://git.alpinelinux.org/aports/tree/main/wpa_supplicant/0001-nl80211-add-extra-ies-only-if-allowed-by-driver.patch?h=3.20-stable Arch: https://gitlab.archlinux.org/archlinux/packaging/packages/wpa_supplicant/-/blob/main/0007-nl80211-add-extra-ies-only-if-allowed-by-driver.patch?ref_type=heads Debian: https://sources.debian.org/src/wpa/2:2.10-22/debian/patches/upstream-fixes/0001-nl80211-add-extra-ies-only-if-allowed-by-driver.patch/ OpwnWRT: https://github.com/openwrt/openwrt/blob/580ad3e6bb57216706dfb9bc44875cfc4ca41feb/package/network/services/hostapd/patches/051-nl80211-add-extra-ies-only-if-allowed-by-driver.patch Gentoo (no patch): https://gitweb.gentoo.org/repo/gentoo.git/tree/net-wireless/wpa_supplicant/files
Hello, After digging the Web, there seems that a fix is possible for the broadcom-wl driver (not brcmfmac) without the need to modify wpa_supplicant 2.11. See rpmfusion bug report here for the fixed broadcom-wl driver: https://bugzilla.rpmfusion.org/show_bug.cgi?id=7030 I know that's not exactly the right place to answer or to post some links to a third-party repository, but the number of users that posted some messages in this bug report and that use the broadcom-wl driver, lead me to make this comment. In short, the fix was inspired by: https://patchwork.kernel.org/project/linux-wireless/patch/20211212221310.5453-1-merlijn@wizzup.org/ It consists to add and set max_scan_ie_len in the broadcom-wl driver sources, even if the driver itself doesn't use it, but this will let wpa_supplicant do his work without failing when asking the value of max_scan_ie_len to the driver. For my part, the modified broadcom-wl driver seems to work correctly on my old laptop with a BCM4313 wireles device on f40 with wpa_supplicant-2.11-3.fc40.x86_64. So it seems that there is no need to patch wpa_supplicant for the moment for this driver (keeping the links to the patches somewhere not so far). Tests and feedback are welcome for the broadcom-wl driver, but on the rpmfusion bug report please. As already said, I don't know if the fix available for broadcom-wl driver is accurate for brcmfmac. If the last version of the wpa_supplicant package had already fixed the issue for brcmfmac driver, maybe this bug report should be closed after a while to let users read this thread and apply the correct fix for their cases. Cordially, -- NVieville
(In reply to nicolas.vieville from comment #42) > Hello, > > After digging the Web, there seems that a fix is possible for the > broadcom-wl driver (not brcmfmac) without the need to modify wpa_supplicant > 2.11. > See rpmfusion bug report here for the fixed broadcom-wl driver: > > https://bugzilla.rpmfusion.org/show_bug.cgi?id=7030 > > I know that's not exactly the right place to answer or to post some links to > a third-party repository, but the number of users that posted some messages > in this bug report and that use the broadcom-wl driver, lead me to make this > comment. > > In short, the fix was inspired by: > > https://patchwork.kernel.org/project/linux-wireless/patch/20211212221310. > 5453-1-merlijn/ > > It consists to add and set max_scan_ie_len in the broadcom-wl driver > sources, even if the driver itself doesn't use it, but this will let > wpa_supplicant do his work without failing when asking the value of > max_scan_ie_len to the driver. > > For my part, the modified broadcom-wl driver seems to work correctly on my > old laptop with a BCM4313 wireles device on f40 with > wpa_supplicant-2.11-3.fc40.x86_64. So it seems that there is no need to > patch wpa_supplicant for the moment for this driver (keeping the links to > the patches somewhere not so far). > Tests and feedback are welcome for the broadcom-wl driver, but on the > rpmfusion bug report please. > > As already said, I don't know if the fix available for broadcom-wl driver is > accurate for brcmfmac. > If the last version of the wpa_supplicant package had already fixed the > issue for brcmfmac driver, maybe this bug report should be closed after a > while to let users read this thread and apply the correct fix for their > cases. > > Cordially, > > > -- > NVieville The new fix you made works for me! I'm not an expert in this mess, but the broadkom 'wl' case looks like this to me : Modifying 1) wpa_supplicant or 2) broadkom 'wl' is like saying the same thing in a different way. 1) If wpa_supplicant is not modified the request that runs down to cfg80211 or nl80211 I don't know, it fails with -EINVAL i.e. -22 because 'wl' by default fills max_scan_ie_len with 0. 1) If wpa_supplicant is modified it understands about max_scan_ie_len and initializes it in wiphy_info_handler(), then the request does not fail 3) If broadkom 'wl' is modified it directly tells that max_scan_ie_len is 512 and everything is OK
This bug is about brcmfmac, not out of tree drivers, this bug is now fixed (both at the kernel and wpa_supplicant level). For broadcom-wl out of tree driver you need to report the bug fix where ever it's upstream is. There it more than enough details for those users to work out how to deal with it.
(In reply to Peter Robinson from comment #44) > This bug is about brcmfmac, not out of tree drivers, this bug is now fixed > (both at the kernel and wpa_supplicant level). For broadcom-wl out of tree > driver you need to report the bug fix where ever it's upstream is. There it > more than enough details for those users to work out how to deal with it. ... this a know issue since a lot of time. We also tried that patch when it was posted years ago [1] [1] https://bugzilla.redhat.com/show_bug.cgi?id=1703745#c84 but we didn't have so much positive feedback.
FYI, as a user using broadcom-wl, I am still affected by this issue, even after updating to the latest available wpa_supplicant package on Fedora 40. I downgraded which worked. Wanted to report here in case the broadcom-wl use case was overlooked. Thanks for investigating this issue!
(In reply to triguy from comment #46) > FYI, as a user using broadcom-wl, I am still affected by this issue, even > after updating to the latest available wpa_supplicant package on Fedora 40. > I downgraded which worked. Wanted to report here in case the broadcom-wl use > case was overlooked. Thanks for investigating this issue! Hello triguy, Did you tried what I suggested in comment #42. If not, please give it a try and post your feedback in the appropriate bug report on rpmfusion: https://bugzilla.rpmfusion.org/show_bug.cgi?id=7030 We're trying to find a fix without modifying upstream wpa_supplicant sources (see comment from Peter Robinson, Adam Williamson and Davide Caratti). The fix proposed in rpmfusion repository, where you got your wireless device driver package, seems to work for some users who reported it. Maybe it will be the case for you. If you could post some feedback on the rpmfusion bug report, it would be great. Cordially, -- NVieville