Description of problem: NetworkManager allows to create wifi hotspots which have a name. The hotspot SSID name can be editted to some arbitary string; however if you change the SSID and save it (via /etc/sysconfig/network-scripts/ifcfg-Hotspot or nm-connection-editor), the next time you start your wifi hotspot, the hotspot name reverts back to the hostname. Even edit, save, restarting networkmanager, start wifi hotspot has same bug behaviour. Running under cinnamon desktop and enabling using NetworkManager applet This used to work as expected in F24. Version-Release number of selected component (if applicable): Fedora 26 NetworkManager.x86_64 1:1.8.2-1.fc26 How reproducible: Every time Steps to Reproduce: 1. From X desktop, goto NetworkManager -> Network Connections location "Hotspot" under "Wifi" subsection and "Edit" 2. Change SSID name and save 3. vefify name change is persisted /etc/sysconfig/network-scripts/ifcfg-Hotspot 4. goto NetwokrManager -> NetworkSettings 5. click "Use as Hotspot.." and "Turn On" 5. the "Network Name" in dialog shows that the SSID has been reverted to the hostname Actual results: Hotspot SSID changed to hostname Expected results: hotspot SSID to be honoured when hotspot is enabled and no overwriting/updating of /etc/sysconfig/network-scripts/ifcfg-Hotspot Additional info: Worked under Fedora 24
The "Network Settings" dialog is part of cinnamon control center and it resets the SSID to the system hostname every time the hotspot functionality is activated. Updating the bug component.
Does gnome-control-center do the same?, fedora cinnamon-control-center was recently rebased to 3.24.3 https://github.com/linuxmint/cinnamon-control-center/pull/189 Looking at the gnome commits it is the intended behaviour. https://bugzilla.gnome.org/show_bug.cgi?id=705546
(In reply to leigh scott from comment #2) > Does gnome-control-center do the same?, fedora cinnamon-control-center was > recently rebased to 3.24.3 > > > https://github.com/linuxmint/cinnamon-control-center/pull/189 > > > Looking at the gnome commits it is the intended behaviour. > > https://bugzilla.gnome.org/show_bug.cgi?id=705546 network-manager-applet (nm-connection-editor) is a gnome component so it shouldn't try to set hotspot name if gnome-control-center doesn't support it.
After a discussion with Leigh about the reported bug and the fact it is intended behaviour from "Network Settings" in GNOME Control Center to reset the name of the hotspot to the machine's hostname on activation, I think GNOME should not ship tools that are contradicting and conflicting in their intended functionality.
(In reply to Björn "besser82" Esser from comment #4) > After a discussion with Leigh about the reported bug and the fact it is > intended behaviour from "Network Settings" in GNOME Control Center to reset > the name of the hotspot to the machine's hostname on activation, I think > GNOME should not ship tools that are contradicting and conflicting in their > intended functionality. What is contradicting? nm-connection-editor (as the name says) is a editor of NM profiles (connections) and the "hotspot" generated by gnome-control-center is a normal wi-fi connection with mode=AP. I don't think that nm-c-e should prevent users from editing connections just because other tools created them. Also, how nm-c-e should detect that the connection was created by control-center, by the name? (if so, if users create a connection named "Hotspot", they won't be able to edit the connection again). In my opinion when users activate the hotspot fuctionality, control-center should either (1) reuse the existing profile if it is compatible (right SSID, device, ...) or (2) create a new one.
(In reply to Beniamino Galvani from comment #5) > In my opinion when users activate the hotspot fuctionality, > control-center should either (1) reuse the existing profile if it is > compatible (right SSID, device, ...) or (2) create a new one. The better option would be, if nm-c-e would warn a user about g-c-c might clobber any customization made to a profile named "Hotspot" or if a such named profile is created by the user…
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. 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 '26'. 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 26 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 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I've confirmed this is still an issue on Fedora 29. Seems like there should be a better solution than forcing the name of the hotspot to be the hostname of the device. Changes made to "Hotspot" in `nm-connection-editor` should be honored when the connection is activated.
This article shows a possible workaround for this issue, but I have not confirmed it working yet: https://www.linuxuprising.com/2018/09/how-to-create-wi-fi-hotspot-in-ubuntu.html The suggested workaround is to enable the hotspot via the "Connect to Hidden Network..." menu rather than the "Turn On Wi-Fi Hotspot..." menu to avoid the settings being stomped.
this bug is assigned to "network-manager-applet" component. "network-manager-applet" brings two packages: "nm-connection-editor" and "nm-applet". Note that Gnome 3 provides two similar (but different) components: (the network part of) gnome-control-center and (the network part of) gnome-shell. Neither nm-c-e nor nm-a has this behaviour of renaming the hotspot profile when activating it. > After a discussion with Leigh about the reported bug and the fact it is intended behaviour from "Network Settings" in GNOME Control Center to reset the name of the hotspot to the machine's hostname on activation, I think GNOME should not ship tools that are contradicting and conflicting in their intended functionality. According to comment 4, this is intended behavior. I don't think that's best though, because when I connect my smart phone to the hotspot, then the credentials (and the network) are tied to the SSID. Changing the SSID effectively creates a different network, and I need to configure the network on my phone again. This is complicated by the fact that the hostname often gets obtained via DHCP, that means, depending on where I connect my laptop, the laptop will have a different hostname and a different hotspot gets created. That's inconvenient. In any case, it's not a problem of nm-applet or nm-connection-editor. It however may affects gnome-shell/gnome-control-center and cinnamon-control-center. Related discussion: https://github.com/NetworkManager/NetworkManager/pull/154
ok, comment 3 and comment 4 states that this is preferable behavior. Assigning back to cinnamon-control-center. Please close as WONTFIX if this want to keep this behavior, or possibly coordinate with gnome-control-center.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. 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 '29'. 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 29 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 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.