Bug 1996918
Summary: | "nmcli radio all" shows wifi enabled even although there is no wifi hardware | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Jonathan Maxwell <jmaxwell> |
Component: | NetworkManager | Assignee: | Beniamino Galvani <bgalvani> |
Status: | CLOSED ERRATA | QA Contact: | Matej Berezny <mberezny> |
Severity: | unspecified | Docs Contact: | |
Priority: | medium | ||
Version: | 8.4 | CC: | bdm, bgalvani, ferferna, fge, fpokryvk, jentrena, lrintel, mberezny, pdwyer, rkhan, sukulkar, thaller, till, tony.horton, wenliang, zakariye.mohamed |
Target Milestone: | rc | Keywords: | Reopened, Triaged |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | NetworkManager-1.37.3-1.el8 | Doc Type: | No Doc Update |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2022-11-08 10:07:31 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 2090344 |
Description
Jonathan Maxwell
2021-08-24 02:14:57 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? (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." 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. 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? 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. (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) 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. (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. (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. 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” (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 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? Any updates on my question above will be appreciated. Thanks Any updates on my question above will be appreciated. Thanks (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. 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." 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. 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 |