Description of problem: After doing a dnf system-upgrade from F31 to F32, the wi-fi hotspot does not work. In gnome wi-fi settings tool, "Turn On Wi-Fi Hotspot" button is grayed out, and hovering with pointer displays "System policy prohibits use as a Hotspot". Version-Release number of selected component (if applicable): selinux-policy-3.14.5-32.fc32.noarch How reproducible: 100% Steps to Reproduce: 1. In gnome, go to Wi-Fi settings 2. Turn on Wi-Fi 3. Hover mouse over "Turn On Wi-Fi Hotspot" Actual results: "Turn On Wi-Fi Hotspot" button is grayed out. Expected results: "Turn On Wi-Fi Hotspot" is not grayed out. Clicking on it turns on Hotspot. Additional info: When wi-fi is turned on the list of visible networks is displayed as usual. $ nmcli radio wifi on $ nmcli con up id "Hotspot" turns on the Hotspot, but it is unusable for some reason. The Hotspot displays as on in the Gnome settings, and the tool allows you to turn the Hotspot off.
Don, How did you find out it was denied by SELinux? Was there a sealert window? To understand the issue, we would need the avc denial, either from sealert or collected by ausearch: # ausearch -i -m avc,user_avc -ts recent
(In reply to Zdenek Pytela from comment #1) > Don, > > How did you find out it was denied by SELinux? Was there a sealert window? > To understand the issue, we would need the avc denial, either from sealert > or collected by ausearch: > > # ausearch -i -m avc,user_avc -ts recent # ausearch -i -m avc,user_avc -ts recent <no matches> I assumed it was a SELinux issue because of the info message given when you hover the pointer over the "Turn On Wi-FI Hotspot..." button: "System policy prohibits use as a Hotspot". sealert doesn't show any issues.
It looks like the proper component for this bug may be nftables, not selinux-policy. # nft list ruleset does not show any entries for wlp2s0, the hotspot network device. When the hotspot is turned on with nmcli, journalctl repeatedly shows: ... wlp2s0: AP-STA-CONNECTED ... ... wlp2s0: AP-STA-DISCONNECTED ... My nook connects and shows "Obtaining IP address...", but never gets past that.
I don't think this has anything to do with nftables. ;) I think it's NetworkManager not setting things up for you. Can you attach the logs from NetworkManager ? 'journalctl -b -l -u NetworkManager'
Created attachment 1683421 [details] NetworkManager log As requested.
Moving to NetworkManager for comment...
NetworkManager adds some iptables rules to allow DHCP and DNS from the wireless clients to the local interface, but I see that on F32 all incoming DHCP packets are dropped. Doing: nmcli connection modify Hotspot connection.zone trusted seems to solve the problem here. I don't know what changed from F31 to cause this issue. I'm reassigning this bz to firewalld for investigation.
$ nmcli connection modify Hotspot connection.zone trusted allowed my nook to connect, after turning on the Hotspot with nmcli. Thanks.
(In reply to Beniamino Galvani from comment #7) > I don't know what changed from F31 to > cause this issue. I'm reassigning this bz to firewalld for > investigation. This Change happened: https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables#Upgrade.2Fcompatibility_impact firewalld now defaults to the nftables backend. I expect this is fallout from the "behavioral changes" highlight in the linked section. A couple options: 1) add services "dhcp" and "dns" to the appropriate zone (whatever the wireless interface is assigned to) or 2) a less than ideal workaround is to revert firewalld to the iptables backend. See FirewallBackend in man page firewalld.conf(5). This really can't be fixed in firewalld. iptables and nftables are separate and independent firewalls. The packets must make it through both.
(In reply to Eric Garver from comment #9) > A couple options: > > 1) add services "dhcp" and "dns" to the appropriate zone (whatever the > wireless interface is assigned to) > or > 2) a less than ideal workaround is to revert firewalld to the iptables > backend. See FirewallBackend in man page firewalld.conf(5). Would it be possible to configure all the firewalls rules including masquerading through firewalld? For example we could have a 'shared' zone with 'dhcp' and 'dns' services, and 'masquerade'. NM would set that zone for the interface or in alternative for the source subnet of the shared interface (e.g. 10.42.0.0/24). Or maybe it could use rich rules without a zone? NM could try first to set firewall rules through firewalld and if it fails then fall back to the current implementation that uses iptables.
(In reply to Beniamino Galvani from comment #10) > (In reply to Eric Garver from comment #9) > > A couple options: > > > > 1) add services "dhcp" and "dns" to the appropriate zone (whatever the > > wireless interface is assigned to) > > or > > 2) a less than ideal workaround is to revert firewalld to the iptables > > backend. See FirewallBackend in man page firewalld.conf(5). > > Would it be possible to configure all the firewalls rules including > masquerading through firewalld? Everything but masquerading. Firewalld masquerades based on the _outgoing_ zone. I expect NM wants to masquerade based on a source address mask, e.g. 10.10.10.0/24. > For example we could have a 'shared' zone with 'dhcp' and 'dns' > services, and 'masquerade'. NM would set that zone for the interface > or in alternative for the source subnet of the shared interface > (e.g. 10.42.0.0/24). Using a "source" of 10.42.0.0/24 and enabling masquerade in the zone means firewalld will attempting to masquerading packets with _destination_ 10.42.0.0/24. > Or maybe it could use rich rules without a zone? Rich rules must be bound to a zone. > NM could try first to set firewall rules through firewalld and if it > fails then fall back to the current implementation that uses iptables. I think for the time being NM will have to continue doing masquerade via iptables. But NM can use a shared zone to allow DHCP and DNS. This is very similar to what libvirt does.
Upstream merge request: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/498
https://bodhi.fedoraproject.org/updates/FEDORA-2020-67d0eb6ccc
In F33, the Hotspot can be created and turned on and off from Gnome settings. The Wifi must be turned on first. It works the way it did in F31. Leaving bug open, since I cannot address the other issues raised by this bug.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. 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 '32'. 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 32 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 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 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.