SUMMARY *** Can not connect any device to WAP/WAP2/WAP3 shared network created through plasma-nm *** STEPS TO REPRODUCE 1. Create a shared wifi network with any of the above security protocol 2. Try to connect another device by entering the password for above network, or scanning the QR code OBSERVED RESULT Device cannot connect to the network and displays error for incorrect password EXPECTED RESULT Plasma-nm should create a shared wifi network such that other devices can connect to it SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.16 (available in About System) KDE Plasma Version: 5.23 KDE Frameworks Version: 5.90 Qt Version: 5.15 ADDITIONAL INFORMATION Shared wifi network created through other means (like linux-wifi-hotspot utility) can be connected by other devices. Bug has been present for as long as I can remember
What distribution does this happen on for you? I have a feeling this bug depends heavily on non-KDE components. Also to be clear, unencrypted hotspot works, right?
(In reply to Alois Wohlschlager from comment #1) > What distribution does this happen on for you? I have a feeling this bug At present, I can confirm it on manjaro and kde neon installed on seperate hardware. I have also had this issue in ubuntu but that was many years before. > depends heavily on non-KDE components. Also to be clear, unencrypted hotspot > works, right? Yes, unencrypted hotspot works. Also encrypted hotspots created through utilities like linux-wifi-hotspot also work
I think this is wpa_supplicant somehow failing to create a WPA3 hotspot properly. To confirm, can you please try the following (adjust <interface> and <passphrase> appropriately): $ cat > hostapd.conf <<EOF interface=<interface> ssid=hotspot wpa=2 wpa_key_mgmt=SAE wpa_passphrase=<passphrase> EOF $ sudo hostapd hostapd.conf Then try to connect to the hotspot using a different device after the AP-ENABLED message appears. Then, please report whether hostapd prints anything else.
I got this error: ACS: Automatic channel selection started, this may take a bit wlp0s29u1u5: interface state UNINITIALIZED->ACS wlp0s29u1u5: ACS-STARTED ACS: Unable to collect survey data ACS: All study options have failed Interface initialization failed wlp0s29u1u5: interface state ACS->DISABLED wlp0s29u1u5: AP-DISABLED ACS: Possibly channel configuration is invalid, please report this along with your config file. ACS: Failed to start wlp0s29u1u5: AP-DISABLED hostapd_free_hapd_data: Interface wlp0s29u1u5 wasn't started nl80211: deinit ifname=wlp0s29u1u5 disabled_11b_rates=0 wlp0s29u1u5: interface state DISABLED->DISABLED wlp0s29u1u5: interface state DISABLED->DISABLED wlp0s29u1u5: AP-DISABLED wlp0s29u1u5: CTRL-EVENT-TERMINATING hostapd_free_hapd_data: Interface wlp0s29u1u5 wasn't started
This is likely unrelated, try running on a fixed channel by adding a line "channel=1" (without quotes) to the hostapd.conf.
(In reply to Alois Wohlschlager from comment #5) > This is likely unrelated, try running on a fixed channel by adding a line > "channel=1" (without quotes) to the hostapd.conf. It worked after putting channel=1. However, the hotspot so created still can't be connected by any device and shows incorrect password (the same error as with plasma-nm)
Anything I should report further? Still have the error in 5.27
My adapter broke, and I cannot reproduce the bug with the new device any more. Since we already figured out the bug is likely not in Plasma, I'd try the hostap mailing list. The problem appears to be that some device/driver/wpa_supplicant combinations fail to set up a WPA3 access point properly.
(In reply to Alois Wohlschlager from comment #8) > My adapter broke, and I cannot reproduce the bug with the new device any > more. Since we already figured out the bug is likely not in Plasma, I'd try > the hostap mailing list. The problem appears to be that some > device/driver/wpa_supplicant combinations fail to set up a WPA3 access point > properly. Thanks a lot. I tried to mail hostap but it keeps blocking my mail for some reason and I couldn't figure out where I should report them the bug. Also, I have issue with both WPA2 and WPA3 encryption.
> Thanks a lot. I tried to mail hostap but it keeps blocking my mail for some > reason and I couldn't figure out where I should report them the bug. I have no experience with this list in particular, but it is likely that the first message sent from a new email address needs moderator approval (this is a common process to prevent spam). > Also, I have issue with both WPA2 and WPA3 encryption. You actually don't. When you tell NetworkManager to create a WPA2 access point, it actually creates a hybrid WPA2/WPA3 access point. Your other device prefers to connect to WPA3 and subsequently fails.
For what it's worth, I found a workaround for my connection from a comment on Red Hat Bugzilla bug 2057352. I had to use the interactive mode of nmcli to set the Protected Management Frames (802.11w) off: $ nmcli connection edit My_Hotspot > set wifi-sec.pmf 1 > save > quit 0 means "global default", 1 means "disable", etc. The command lspci shows my adapter as "Intel Corporation Wireless 8265 / 8275 (rev 78)".
(In reply to Simo Sutela from comment #11) > For what it's worth, I found a workaround for my connection from a comment > on Red Hat Bugzilla bug 2057352. I had to use the interactive mode of nmcli > to set the Protected Management Frames (802.11w) off: > > $ nmcli connection edit My_Hotspot > > set wifi-sec.pmf 1 > > save > > quit > > 0 means "global default", 1 means "disable", etc. The command lspci shows my > adapter as "Intel Corporation Wireless 8265 / 8275 (rev 78)". I tried it too but it did not solve the issue in my case
I have a similar issue -- in my case, a set of Samsung Galaxy phones (S20 and S23) have been unable to connect for a few months; a laptop running Debian testing could. I finally got tired of it and searched, and found this post on the Arch Linux forums: https://bbs.archlinux.org/viewtopic.php?id=293307 The original poster complains that his hotspot does not work when created from KDE, but doing the same from Gnome does make it work. The reply says to run: nmcli connection modify WIFI-Share 802-11-wireless-security.proto wpa where "WIFI-Share" is the name of the WIFI configuration created for the hotspot. I did that, and it solved the problem for me. I should note that I encountered the problem at first a couple of years ago, and then switching from wpa-supplicant to iwd mostly fixed things (it still had minor issues). But for several months, this stopped working too. Anyway, I find it hard to believe that the problem can be brushed aside as "not in plasma" when it works in Gnome.
(In reply to Shai from comment #13) > I have a similar issue -- in my case, a set of Samsung Galaxy phones (S20 > and S23) have been unable to connect for a few months; a laptop running > Debian testing could. That's quite interesting, this is the first report of the bug also depending on the client device. > I finally got tired of it and searched, and found this post on the Arch > Linux forums: > https://bbs.archlinux.org/viewtopic.php?id=293307 > > The original poster complains that his hotspot does not work when created > from KDE, but doing the same from Gnome does make it work. Thank you for this information, this is quite helpful since we can now determine what configuration can be applied to make it work. Notably, the configuration created by GNOME contains the following settings in its nmconnection file that the KDE one does not: group=ccmp; pairwise=ccmp; proto=rsn; > The reply says to run: > > nmcli connection modify WIFI-Share 802-11-wireless-security.proto wpa > > where "WIFI-Share" is the name of the WIFI configuration created for the > hotspot. I did that, and it solved the problem for me. This is not a very good idea, since it disables WPA2 and only leaves you with WPA. Can you try the following and report if and at what place things begin to work? (You either have to set up a fresh connection or undo the above command with 'nmcli connection modify WIFI-Share 802-11-wireless-security.proto ""' (two double quotes at the end).) nmcli connection modify WIFI-Share 802-11-wireless-security.group ccmp nmcli connection modify WIFI-Share 802-11-wireless-security.pairwise ccmp nmcli connection modify WIFI-Share 802-11-wireless-security.proto rsn > I should note that I encountered the problem at first a couple of years ago, > and then switching from wpa-supplicant to iwd mostly fixed things (it still > had minor issues). But for several months, this stopped working too. I wouldn't be surprised if the "several months" coincided with the release of iwd 2.18, which introduced WPA3 support. Can you confirm this if convenient? It would either mean that hostapd and iwd have the same bug, or it's at a lower level (driver, firmware or hardware). > Anyway, I find it hard to believe that the problem can be brushed aside as > "not in plasma" when it works in Gnome. The underlying bug unlikely to be in Plasma since the problem can be reproduced with plain hostapd without adding weird settings. That does not mean that Plasma can't add a workaround if an upstream fix can't be expected. Since you have figured out that it works in GNOME, that workaround could even consist of setting whatever GNOME does to make it work.
Hi, Thanks, this is very helpful! (In reply to Alois Wohlschlager from comment #14) > (In reply to Shai from comment #13) > > The reply says to run: > > > > nmcli connection modify WIFI-Share 802-11-wireless-security.proto wpa > > > > where "WIFI-Share" is the name of the WIFI configuration created for the > > hotspot. I did that, and it solved the problem for me. > > This is not a very good idea, since it disables WPA2 and only leaves you > with WPA. Thanks for the heads-up! > Can you try the following and report if and at what place things > begin to work? (You either have to set up a fresh connection or undo the > above command with 'nmcli connection modify WIFI-Share > 802-11-wireless-security.proto ""' (two double quotes at the end).) > > nmcli connection modify WIFI-Share 802-11-wireless-security.group ccmp > nmcli connection modify WIFI-Share 802-11-wireless-security.pairwise ccmp > nmcli connection modify WIFI-Share 802-11-wireless-security.proto rsn > Will check later, when it's more convenient. > > I should note that I encountered the problem at first a couple of years ago, > > and then switching from wpa-supplicant to iwd mostly fixed things (it still > > had minor issues). But for several months, this stopped working too. > > I wouldn't be surprised if the "several months" coincided with the release > of iwd 2.18, which introduced WPA3 support. Can you confirm this if > convenient? It would either mean that hostapd and iwd have the same bug, or > it's at a lower level (driver, firmware or hardware). > I can't be completely sure -- but I upgraded from iwd 2.17 to 2.19 on July 21, and removed iwd (that is, gave up on trying to make it work) on August 16 (the system providing the hotspot is also Debian testing). > > Anyway, I find it hard to believe that the problem can be brushed aside as > > "not in plasma" when it works in Gnome. > > The underlying bug unlikely to be in Plasma since the problem can be > reproduced with plain hostapd without adding weird settings. FWIW I don't have hostapd installed, and never heard of it before the searches I did yesterday. > That does not mean that Plasma can't add a workaround if an upstream fix can't be > expected. Since you have figured out that it works in GNOME, that workaround > could even consist of setting whatever GNOME does to make it work. That makes perfect sense (except credit for finding that it works in Gnome should go to Vamp898 from the Arch Linux forum). Thanks!
(In reply to Alois Wohlschlager from comment #14) > Thank you for this information, this is quite helpful since we can now > determine what configuration can be applied to make it work. Notably, the > configuration created by GNOME contains the following settings in its > nmconnection file that the KDE one does not: > > group=ccmp; > pairwise=ccmp; > proto=rsn; > [...] > Can you try the following and report if and at what place things > begin to work? (You either have to set up a fresh connection or undo the > above command with 'nmcli connection modify WIFI-Share > 802-11-wireless-security.proto ""' (two double quotes at the end).) > > nmcli connection modify WIFI-Share 802-11-wireless-security.group ccmp > nmcli connection modify WIFI-Share 802-11-wireless-security.pairwise ccmp > nmcli connection modify WIFI-Share 802-11-wireless-security.proto rsn > After the second of these (nmcli connection modify WIFI-Share 802-11-wireless-security.pairwise ccmp) things started to work.
Bulk transfer as requested in T17796
Hello, I was having the same hotspot problem with WPA/WPA2/WPA3. I would get wpa_supplicant: CTRL-EVENT-SCAN-FAILED ret=-95 Same fix worked. SOFTWARE/OS VERSIONS NixOS 25.05 KDE Plasma 6.3.2 NetworkManager, version 1.52.0