Bug 1829637

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.