Bug 1829637 - Wi-Fi hotspot stopped working after upgrade to F32
Summary: Wi-Fi hotspot stopped working after upgrade to F32
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 32
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Beniamino Galvani
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1895374
TreeView+ depends on / blocked
 
Reported: 2020-04-29 23:04 UTC by Don Swaner
Modified: 2021-05-25 18:15 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1895374 (view as bug list)
Environment:
Last Closed: 2021-05-25 18:15:28 UTC
Type: Bug


Attachments (Terms of Use)
NetworkManager log (52.92 KB, text/plain)
2020-04-30 18:17 UTC, Don Swaner
no flags Details

Description Don Swaner 2020-04-29 23:04:06 UTC
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.

Comment 1 Zdenek Pytela 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

Comment 2 Don Swaner 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.

Comment 3 Don Swaner 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.

Comment 4 Kevin Fenzi 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'

Comment 5 Don Swaner 2020-04-30 18:17:04 UTC
Created attachment 1683421 [details]
NetworkManager log

As requested.

Comment 6 Kevin Fenzi 2020-04-30 19:21:46 UTC
Moving to NetworkManager for comment...

Comment 7 Beniamino Galvani 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.

Comment 8 Don Swaner 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.

Comment 9 Eric Garver 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.

Comment 10 Beniamino Galvani 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.

Comment 11 Eric Garver 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.

Comment 12 Beniamino Galvani 2020-05-08 07:50:34 UTC
Upstream merge request:

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

Comment 14 Don Swaner 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.

Comment 15 Fedora Program Management 2021-04-29 17:16:15 UTC
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.

Comment 16 Ben Cotton 2021-05-25 18:15:28 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.