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 1530391 - WIFI enabled by default in RHEL 7
Summary: WIFI enabled by default in RHEL 7
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.4
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: sushil kulkarni
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-01-02 21:16 UTC by mcolombo
Modified: 2021-03-11 16:47 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-21 17:03:19 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description mcolombo 2018-01-02 21:16:17 UTC 
Description of problem:
wifi enabled by default with server OS

Version-Release number of selected component (if applicable):
3.10.0-693.5.2.el7.x86_64


How reproducible:
every time

Steps to Reproduce:
1. Install RHEL server
2.
3.

Actual results:
$ cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.3 (Maipo)

$ uname -r
3.10.0-514.10.2.el7.x86_64 (Also confirmed on 3.10.0-693.5.2.el7.x86_64)

$ nmcli r
WIFI-HW  WIFI     WWAN-HW  WWAN    
enabled  enabled  enabled  enabled

$ systemctl list-unit-files | grep Network

dbus-org.freedesktop.NetworkManager.service   enabled 
NetworkManager-dispatcher.service             enabled 
NetworkManager-wait-online.service            disabled
NetworkManager.service                        enabled

$ yum list installed | grep Network
NetworkManager.x86_64               1:1.8.0-9.el7  

# lspci | grep -i ethernet
00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
00:09.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03)
00:0a.0 Ethernet controller: Red Hat, Inc Virtio network device


Expected results:
$ nmcli r
WIFI-HW  WIFI     WWAN-HW  WWAN    
disabled disabled disabled disabled


Additional info:
Customer is concerned about WIFI being enabled by default in a `server` OS even though wireless devices are not present. Customer states that wifi should not be enabled by default on a server especially if a wifi device is not present and believes this is a bug.
Comment 2 Thomas Haller 2018-01-03 13:35:43 UTC 
Devices may appear anytime. For example when plugging in a USB Wi-Fi device. Or when kernel is just slow at discovering the hardware. Or when the kernel module is not loaded at the moment. NetworkManager cannot know whether that will happen  (or if/when).

The rfkill flags are hence always present -- even if there is no device. 
They allow you to block Wi-Fi from the first moment when the Wi-Fi device shows up. If you don't have a Wi-Fi device (on the customer's server), they do not matter.


NetworkManager also does not disable rfkill by default. Rather, it assumes that the user wants to make use of a Wi-Fi device.

The user can toggle the flag with `nmcli radio wifi off` or `nmcli networking off`. Such a change is also persisted to file (/var/lib/NetworkManager/NetworkManager.state) so that after reboot the flag is still disabled.


Also, the rfkill flags are composed of an NetworkManager internal decision (software) and a hardware decision (e.g. your notebook as a hardware button do disable the Wi-Fi radio). For rfkill to be cleared, both the software and hardware rfkill flags must be enabled.



> Customer is concerned about WIFI being enabled by default in a `server` OS 
> even though wireless devices are not present. Customer states that wifi should 
> not be enabled by default on a server especially if a wifi device is not
> present and believes this is a bug.

The concerns are not clear to me. what's the problem really? What problems does it cause?

On a server, the customer probably wants to remove the package NetworkManager-wifi. This will uninstall support for NetworkManager to handle Wi-Fi devices, and save a few bytes. After that, Wi-Fi devices are treated as generic and most Wi-Fi functionality is not accessible via NetworkManager (you could still use wpa_supplicant outside of NetworkManager to setup the Wi-Fi device, and only use NetworkManager to only handle the IP addressing).
But as said, the rfkill flags are always present, regardless of whether NM supports Wi-Fi devices actively (meaning the NetworkManager-wifi package).
Comment 3 Thomas Haller 2018-02-21 17:03:19 UTC 
As I tried to explain in comment 1, I think there is no bug here and nothing to change. Closing, but please re-open if you have anything to add. Thanks.
Note You need to log in before you can comment on or make changes to this bug.