Created attachment 1451195 [details]
system journal when activating hotspot mode
Cannot start Hotspot mode on Wi-Fi
Description of the problem:
Hotspot mode is not available in gnome-control-center, in section "Wi-Fi".
Version-Release number of selected component:
Steps to Reproduce:
1. Start gnome-control-center.
2. Open section "Wi-Fi".
3. Turn on Wi-Fi hotspot.
4. Confirm with button "Turn On".
Hotspot mode is not activated.
Hotspot mode is activated and information about the hotspot is displayed.
(gnome-control-center:9376): network-cc-panel-WARNING **: 03:45:20.173: Failed to save hotspot's settings to disk: Could not read file '/etc/sysconfig/network-scripts/ifcfg-Hotspot': No such file or directory
# lspci -s 04:00.0 -nn
04:00.0 Network controller : Intel Corporation Centrino Advanced-N + WiMAX 6250 [Kilmer Peak] [8086:0087] (rev 35)
# lspci -s 04:00.0 -v
04:00.0 Network controller: Intel Corporation Centrino Advanced-N + WiMAX 6250 [Kilmer Peak] (rev 35)
Subsystem: Intel Corporation Centrino Advanced-N + WiMAX 6250 2x2 AGN
Flags: bus master, fast devsel, latency 0, IRQ 30
Memory at f7c00000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Endpoint, MSI 00
Capabilities:  Advanced Error Reporting
Capabilities:  Device Serial Number 00-23-15-ff-ff-0e-d0-4c
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
The same effect appears on diffent hosts.
Those hosts have different Wi-Fi controllers.
I've got this too. Fedora 28, updated September 2, 2018. I get a repeated error message "Connection failed". The same thing happens when I try to set up a hotspot with nm-connection-manager.
It turns out I have this issue on Fedora Atamic Workstation 28 (aka Silverblue). I'd rather do the troubleshooting there - the system with the issue doesn't have enough disk space for both Fedora and Silverblue, and I'm currently using Silverblue.
I doubt if this is actually a GNOME Control Center bug. I get the same result with nm-connection-editor and there are plenty of logs from wpa_supplicant and friends.
The device is a plug-in USB WiFi adapter and it works on Arch Linux. It's an Ralink Technology, Corp. RT5372 Wireless Adapter.
What log files should I capture and post?
Created attachment 1484211 [details]
journalctl log from Silverblue 29 Beta 1.3 attempts
I just upgraded to Silverblue 29 beta 1.3 and I still have the issue. This is a journalctl log of the testing.
Created attachment 1484212 [details]
wpa_supplicant config file 1 of 2
There are two wpa_supplicant config files on the system. This is the one from /etc/wpa_supplicant
Created attachment 1484213 [details]
wpa_supplicant config file 2 of 2
There are two wpa_supplicant.conf files on my system. This is the one from /dbus-1/system.d
Created attachment 1485855 [details]
Fedora 29 Workstation Live Beta 1.5 - journalctl log of failed hotspot start
Trying to bring up the hotspot on Fedora 29 Workstation Live beta 1.5. Symptoms are the same as with Silverblue - hotspot comes up for a bit but then fails.
(In reply to M. Edward (Ed) Borasky from comment #7)
> Created attachment 1485855 [details]
> Fedora 29 Workstation Live Beta 1.5 - journalctl log of failed hotspot start
> Trying to bring up the hotspot on Fedora 29 Workstation Live beta 1.5.
> Symptoms are the same as with Silverblue - hotspot comes up for a bit but
> then fails.
I now have the hotspot working on Silverblue 29 with a Ralink Technology, Corp. RT5372 Wireless Adapter USB WiFi adapter using "create_ap" (https://github.com/oblique/create_ap). I can now get journalctl logs from a successful create_ap and an unsuccessful NetworkManager attempt. I'll post those a bit later.
Created attachment 1518321 [details]
journalctl log from failed NetworkManager hotspot creation
Created attachment 1518323 [details]
journalctl log from successful create_ap hotspot creation
How I generated the logs:
1. Removed the 'unmanaged' flag from the device with 'create_ap'
2. Used 'nm-connection-editor' to create a hotspot. It started up but crashed within 30 seconds. That's 'NetworkManager.journalctl'
3. Used 'create_ap' to create a hotspot. This worked.
$ sudo create_ap --config .hotspot
Running as Daemon...
Config dir: /tmp/create_ap.wlp0s18f2u5.conf.gzskhcdU
Network Manager found, set wlp0s18f2u5 as unmanaged device... DONE
Sharing Internet using method: nat
hostapd command-line interface: hostapd_cli -p /tmp/create_ap.wlp0s18f2u5.conf.gzskhcdU/hostapd_ctrl
Configuration file: /tmp/create_ap.wlp0s18f2u5.conf.gzskhcdU/hostapd.conf
Using interface wlp0s18f2u5 with hwaddr 9c:ef:d5:fe:a1:f0 and ssid "Famine"
wlp0s18f2u5: interface state UNINITIALIZED->ENABLED
wlp0s18f2u5: STA ac:37:43:e0:16:a9 IEEE 802.11: authenticated
wlp0s18f2u5: STA ac:37:43:e0:16:a9 IEEE 802.11: associated (aid 1)
wlp0s18f2u5: AP-STA-CONNECTED ac:37:43:e0:16:a9
wlp0s18f2u5: STA ac:37:43:e0:16:a9 RADIUS: starting accounting session 34DEB4C89260EEC1
wlp0s18f2u5: STA ac:37:43:e0:16:a9 WPA: pairwise key handshake completed (RSN)
4. Connected to the hotspot with a phone. That's the last two lines above.
5. Did another 'journalctl'. 'create_ap.journal' is all the lines posted *after* 'NetworkManager.journal'.
This looks device-specific. The RT5372 is an older device. It looks like NetworkManager is trying to put it in a mode that it doesn't support. 'create_ap / hostapd' may be more forgiving.
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 28 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.