RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1996918 - "nmcli radio all" shows wifi enabled even although there is no wifi hardware
Summary: "nmcli radio all" shows wifi enabled even although there is no wifi hardware
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: NetworkManager
Version: 8.4
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Beniamino Galvani
QA Contact: Matej Berezny
URL:
Whiteboard:
Depends On:
Blocks: 2090344
TreeView+ depends on / blocked
 
Reported: 2021-08-24 02:14 UTC by Jonathan Maxwell
Modified: 2023-09-07 23:23 UTC (History)
16 users (show)

Fixed In Version: NetworkManager-1.37.3-1.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-08 10:07:31 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker NMT-896 0 None None None 2023-09-07 23:23:01 UTC
Red Hat Issue Tracker RHELPLAN-94536 0 None None None 2021-08-24 02:33:02 UTC
Red Hat Knowledge Base (Solution) 6813841 0 None None None 2022-09-27 01:43:20 UTC
Red Hat Product Errata RHBA-2022:7680 0 None None None 2022-11-08 10:08:04 UTC
freedesktop.org Gitlab NetworkManager NetworkManager-ci merge_requests 1029 0 None opened wifi_hwsim: added @simwifi_nmcli_radio test 2022-04-21 16:13:24 UTC
freedesktop.org Gitlab NetworkManager NetworkManager merge_requests 1157 0 None merged cli: indicate missing radio hardware in "nmcli radio" 2022-03-29 07:39:00 UTC

Description Jonathan Maxwell 2021-08-24 02:14:57 UTC
Description of problem:

"nmcli radio all" shows wifi enabled even although there is no wifi hardware installed.

Version-Release number of selected component (if applicable):

4.18.0-333.el8.x86_64
NetworkManager-1.32.10-1.el8.x86_64

How reproducible:

Always.

Steps to Reproduce:

Just install RHEL8 on a system without wifi hardware for example a KVM VM.

# nmcli radio all
WIFI-HW  WIFI     WWAN-HW  WWAN    
enabled  enabled  enabled  enabled 

Actual results:

Shows that wifi is enabled. 

Expected results:

Report that no wifi hardware exists or similar.

Additional info:

The same behaviour exists on RHEL7, but customers have started to query this behaviour.

Comment 1 Thomas Haller 2021-08-25 07:30:21 UTC
note that a Wi-Fi device could appear at any time. E.g. if you plugin some hardware (like USB).

so it makes sense that you can control the radio also without an actual interface, so that you can disable the radio from the start.


Anyway, what NetworkManager does not abstracts nicely, is that you can have any number of rfkill interfaces (for each Wi-Fi device), but NetworkManager combines them into one. So indeed, that combined Wi-Fi radio toggle exists for any number of Wi-Fi cards (including zero). That part kinda makes sense.

But rfkill handling shuld be significantly improved to expose the individual interfaces.



What is the actual problem that the user has with this? Is it being confused because they have no Wi-Fi hardware?

Comment 2 Jonathan Maxwell 2021-08-30 05:08:07 UTC
(In reply to Thomas Haller from comment #1)
> note that a Wi-Fi device could appear at any time. E.g. if you plugin some
> hardware (like USB).
> 
> so it makes sense that you can control the radio also without an actual
> interface, so that you can disable the radio from the start.
> 
> 
> Anyway, what NetworkManager does not abstracts nicely, is that you can have
> any number of rfkill interfaces (for each Wi-Fi device), but NetworkManager
> combines them into one. So indeed, that combined Wi-Fi radio toggle exists
> for any number of Wi-Fi cards (including zero). That part kinda makes sense.
> 
> But rfkill handling shuld be significantly improved to expose the individual
> interfaces.
> 
> 
> 
> What is the actual problem that the user has with this? Is it being confused
> because they have no Wi-Fi hardware?

Hi Thomas,

From the customer:

"After installing RHEL 8.4 as a VMware guest (esxi v7), we noticed that the wifi radios were on after issuing 'nmcli radio all'. However, we do not have any wireless devices/hardware on the VMware host server. From my understanding, wireless should be disabled if no wireless hardware/devices are detected.  Right now we have an ansible task to disable this, but just wondering if this is normal behavior, and we should continue to disable it after install."

Comment 3 Thomas Haller 2021-08-31 16:44:26 UTC
thank you Jon.

Yes, it's a bit confusing to the user. But it's really harmless :)

I agree, the UX should be improved here... TODO.

Comment 4 Till Maas 2021-08-31 17:50:54 UTC
Can we just remove the current output and show the output of `rfkill list`/tell users to use `rfkill list` instead. Why is this needed in nmcli at all?

Comment 5 Gris Ge 2021-10-12 08:21:59 UTC
For UX, how about use:
 * `No Plugin` when `NetworkManager-wifi.x86_64` or `NetworkManager-wwan.x86_64` not installed.
 * `No HW` when no hardware detected.

Comment 6 Till Maas 2021-11-02 09:46:50 UTC
(In reply to Gris Ge from comment #5)
> For UX, how about use:
>  * `No Plugin` when `NetworkManager-wifi.x86_64` or
> `NetworkManager-wwan.x86_64` not installed.
>  * `No HW` when no hardware detected.

These seem to be two special cases. From what I understand, the confusion here is:

- The manpage states about nmcli radio: Show radio switches status, or enable and disable the switches.
    - This is like the airplane mode in mobile phones. Nmcli is missing bluetooth, though, while rfkill shows it.
- The user expeccted it to show whether or not wifi hardware is present.
- To me, it seems like something that is best handled by rfkill directly instead of using nmcli, so it should be removed
- In case the plugin is not installed, "nmcli radio" still seems to work, I guess the rfkill interface is not part of the plugins
- Whether or not hardware is present is part of the "nmcli dev" commands, so to check whether wifi interfaces are there. So to check whether wifi interfaces are present, the a command like

nmcli --terse --fields type,device device status  | grep ^wifi:

This could be a knowledge base article, I guess.


It might be nice to add something like "nmcli device status --type wifi" to filter devices easier but I don't consider this a priority to track this, here.

- Regarding the missing plugin, I guess it would be nice if "nmcli device wifi" would mention the lack of the plugin but this also does not seem like a priority since desktop installations usually have the plugin installed.

Therefore, my proposal is to close this BZ and potentially track 3 possible improvements upstream or elsewhere:

- Remove/deprecate the nmcli radio feature in favor of the rfkill tool
- Support nmcli device status filtering
- Add error message about missing plugins/hardware to nmcli device wifi (would be two issues, one for plugins, one for hardware)

Comment 12 Till Maas 2021-11-04 12:48:08 UTC
Lubomir, when I run "nmcli radio" on a VW without any wifi hardware, it shows:

WIFI-HW  WIFI      WWAN-HW  WWAN     
enabled  disabled  enabled  disabled 

When would the HW knobs show disabled when no hardware is present? Does it default to enabled? As long as we keep this command "nmcli radio" and there is no hardware and it is not possible/it is not possible to turn it off, "missing" or "unknown" seems like a valid request. What do you think?

Proposed User Story:

As a system administrator, I would like to query the presence of radio hardware on a system so that I can verify security requirements.

Proposed Acceptance criteria:

Given a system without any wifi or wwan hardware, when I run "nmcli radio", then it will not show WIFI-HW or WWAN-HW as enabled.

Comment 13 Lubomir Rintel 2022-01-07 07:28:45 UTC
(In reply to Till Maas from comment #12)
> Lubomir, when I run "nmcli radio" on a VW without any wifi hardware, it
> shows:
> 
> WIFI-HW  WIFI      WWAN-HW  WWAN     
> enabled  disabled  enabled  disabled 
> 
> When would the HW knobs show disabled when no hardware is present? Does it
> default to enabled? As long as we keep this command "nmcli radio" and there
> is no hardware and it is not possible/it is not possible to turn it off,
> "missing" or "unknown" seems like a valid request. What do you think?

This not only has impact on radio interfaces that are there,
but on what would happen once they appear.

On that note, if this is confusing, we could indeed say WIFI-HW=missing in
case it is enabled, but no interfaces are present. In case there's no
hardware is present but the hardware rfkill is  off, we'd still have to say
WIFI-HW=disabled.

Comment 14 Julio Entrena Perez 2022-01-07 10:43:39 UTC
(In reply to Lubomir Rintel from comment #13)

> On that note, if this is confusing, we could indeed say WIFI-HW=missing in
> case it is enabled, but no interfaces are present. In case there's no
> hardware is present but the hardware rfkill is  off, we'd still have to say
> WIFI-HW=disabled.

+1, this would work for customer in case 03073347, for them it's a compliance matter.

Comment 16 Fernando F. Mancera 2022-03-01 08:11:43 UTC
Acceptance criteria:

- Given a Linux system using NetworkManager to handle network configuration and nmcli installed with WIFI enabled and WIFI hardware missing
- When the user runs “nmcli radio all” 
- Then WIFI-HW will show “MISSING”

- Given a Linux system using NetworkManager to handle network configuration and nmcli installed with WIFI disabled and WIFI hardware missing
- When the user runs “nmcli radio all” 
- Then WIFI-HW will show “DISABLED & MISSING”

- Given a Linux system using NetworkManager to handle network configuration and nmcli installed with WIFI enabled and WIFI hardware present
- When the user runs “nmcli radio all” 
- Then WIFI-HW will show “ENABLED”

Comment 18 Beniamino Galvani 2022-03-29 07:41:41 UTC
(In reply to Fernando F. Mancera from comment #16)
> Acceptance criteria:

> - Given a Linux system using NetworkManager to handle network configuration
> and nmcli installed with WIFI disabled and WIFI hardware missing
> - When the user runs “nmcli radio all” 
> - Then WIFI-HW will show “DISABLED & MISSING”

Note that if the Wi-Fi hardware is missing (there is no killswitch), it can't be hw-blocked. It can be sw-blocked, though, and in that case it will be displayed as:

WIFI-HW   WIFI
missing   disabled

Comment 23 moha2zak 2022-09-29 13:52:55 UTC
We have RHEL 8 servers that need WIFI and WWAN-HW to be disabled for security compliance. I am trying to find Ansible Playbook that can disable these setting. In the thread someone mentioned that they have Ansible Playbook to disable nmcli radio wwan-hw/wifi disable. Can you share with us the example of playbook?

Comment 24 moha2zak 2022-10-03 16:04:35 UTC
Any updates on my question above will be appreciated. Thanks

Comment 25 moha2zak 2022-10-03 16:27:02 UTC
Any updates on my question above will be appreciated. Thanks

Comment 26 Thomas Haller 2022-10-04 15:32:54 UTC
(In reply to moha2zak from comment #23)
> We have RHEL 8 servers that need WIFI and WWAN-HW to be disabled for
> security compliance. I am trying to find Ansible Playbook that can disable
> these setting. In the thread someone mentioned that they have Ansible
> Playbook to disable nmcli radio wwan-hw/wifi disable. Can you share with us
> the example of playbook?

Hi moha2zak.

I don't know the mentioned ansible playbook.

Do you mean WIFI-HW+WWAN-HW or WIFI+WWAN?

The HW flags cannot be changed via NetworkManager, they are affected by the system otherwise. Eg. on my notebook there is an Fn key.

The "software" flags WIFI+WWAN can be set via D-Bus API 

  busctl set-property org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager WirelessEnabled b 0
  busctl set-property org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager WWanEnabled b 0

and of course `nmcli radio wifi off ; nmcli radio wwan off`.
These flags get persisted to /var/lib/NetworkManager/NetworkManager.state


You could also deploy a file /var/lib/NetworkManager/NetworkManager.state via ansible.
If you do that, you must to take care that NetworkManager is not running at that time, because this file is only loaded when NetworkManager starts. But if NetworkManager running, you can use D-Bus/nmcli instead.


In any case, please reach out to Red Hat support for proper help. Thanks.

Comment 27 moha2zak 2022-10-04 16:01:59 UTC
Thanks Thomas for quick response..


I was referring this thread where the customer mentioned "Right now we have an ansible task to disable this". We have a bunch of RHEL8 servers that need to be disbled "WIFI and  WWAN". I can disable manually by running "nmcli radio wifi/wwan off, but I was wondering if there is Ansible Module to do this as the customer mentioned below. 

=============================================================================================================================================

Hi Thomas,

From the customer:

"After installing RHEL 8.4 as a VMware guest (esxi v7), we noticed that the wifi radios were on after issuing 'nmcli radio all'. However, we do not have any wireless devices/hardware on the VMware host server. From my understanding, wireless should be disabled if no wireless hardware/devices are detected.  Right now we have an ansible task to disable this, but just wondering if this is normal behavior, and we should continue to disable it after install."

Comment 28 Tony Horton 2022-11-07 04:32:46 UTC
Note that the CIS benchmark suggests disabling this,and suggests using nmcli to do so (probably uses the output for the verification too). So this is a likely source of customers querying this. 
I found this bug because we have disabled it in the past, and all of a sudden all of those machines it is showing enabled again. Not related to this bug, but what brought me here.

Comment 30 errata-xmlrpc 2022-11-08 10:07:31 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (NetworkManager bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7680


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