+++ This bug was initially created as a clone of Bug #1829637 +++

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.

--- Additional comment from Zdenek Pytela on 2020-04-30 06:43:04 UTC ---

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

--- Additional comment from Don Swaner on 2020-04-30 11:11:00 UTC ---

(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.

--- Additional comment from Don Swaner on 2020-04-30 13:43:06 UTC ---

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.

--- Additional comment from Kevin Fenzi on 2020-04-30 17:11:26 UTC ---

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'

--- Additional comment from Don Swaner on 2020-04-30 18:17:04 UTC ---

As requested.

--- Additional comment from Kevin Fenzi on 2020-04-30 19:21:46 UTC ---

Moving to NetworkManager for comment...

--- Additional comment from Beniamino Galvani on 2020-04-30 22:12:29 UTC ---

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.

--- Additional comment from Don Swaner on 2020-04-30 22:35:33 UTC ---

$ nmcli connection modify Hotspot connection.zone trusted

allowed my nook to connect, after turning on the Hotspot with nmcli.  Thanks.

--- Additional comment from Eric Garver on 2020-04-30 23:05:47 UTC ---

(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.

--- Additional comment from Beniamino Galvani on 2020-05-04 06:23:06 UTC ---

(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.

--- Additional comment from Eric Garver on 2020-05-05 12:04:30 UTC ---

(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.

--- Additional comment from Beniamino Galvani on 2020-05-08 07:50:34 UTC ---

Upstream merge request:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/498

--- Additional comment from Beniamino Galvani on 2020-05-21 15:18:43 UTC ---

https://bodhi.fedoraproject.org/updates/FEDORA-2020-67d0eb6ccc

--- Additional comment from Don Swaner on 2020-10-27 22:30:08 UTC ---

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.