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 1368018 - ipv6 would be disabled after change device name
Summary: ipv6 would be disabled after change device name
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.3
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Francesco Giudici
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1470965
TreeView+ depends on / blocked
 
Reported: 2016-08-18 06:53 UTC by Jianlin Shi
Modified: 2018-04-10 13:21 UTC (History)
9 users (show)

Fixed In Version: nm-1.8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 13:19:11 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
NetworkManager debug log (519.31 KB, text/x-vhdl)
2016-08-18 07:46 UTC, Jianlin Shi 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0778 0 None None None 2018-04-10 13:21:22 UTC

Description Jianlin Shi 2016-08-18 06:53:43 UTC 
I don't know if this is a bug of NetworkManager did this way deliberately.so add a bug.

Description of problem:
ipv6 would be disabled after change device name

Version-Release number of selected component (if applicable):
NetworkManager-1.4.0-0.5.beta1.el7.x86_64
3.10.0-489.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. boot system, add "NM_CONTROLLED=no" to ifcfg of device and restart NetworkManager
2. change device name and wait several seconds
3. get device ip through dhclient -v devicename
4. change device name back
5. check disable_ipv6 of device

Actual results:
disable_ipv6 is 1

Expected results:
disable_ipv6 is 0

Additional info:

[root@hp-dl380pg8-12 network-scripts]# cat ifcfg-ens1
TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=ens1
UUID=d4468c97-a84b-4223-9589-5bac938198df
DEVICE=ens1
ONBOOT=no
NM_CONTROLLED=no

[root@hp-dl380pg8-12 network-scripts]# systemctl restart NetworkManager

[root@hp-dl380pg8-12 network-scripts]# ip link set ens1 down
[root@hp-dl380pg8-12 network-scripts]# ip link set ens1 name devname
[root@hp-dl380pg8-12 network-scripts]# ip link sh devname
6: devname: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT qlen 1000
    link/ether 7c:fe:90:bf:1e:80 brd ff:ff:ff:ff:ff:ff

[root@hp-dl380pg8-12 network-scripts]# dhclient -v devname
Internet Systems Consortium DHCP Client 4.2.5
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/devname/7c:fe:90:bf:1e:80
Sending on   LPF/devname/7c:fe:90:bf:1e:80
Sending on   Socket/fallback
DHCPDISCOVER on devname to 255.255.255.255 port 67 interval 7 (xid=0x7f75f37c)
DHCPREQUEST on devname to 255.255.255.255 port 67 (xid=0x7f75f37c)
DHCPOFFER from 192.168.1.253
DHCPACK from 192.168.1.253 (xid=0x7f75f37c)
bound to 192.168.1.172 -- renewal in 43090 seconds.


[root@hp-dl380pg8-12 network-scripts]# ip link set devname down
[root@hp-dl380pg8-12 network-scripts]# ip link set devname name ens1
[root@hp-dl380pg8-12 network-scripts]# cat /proc/sys/net/ipv6/conf/ens1/disable_ipv6 
1
<=========here disable ipv6
Comment 1 Thomas Haller 2016-08-18 07:14:53 UTC 
Hi.

On a restart, the device is left in the previous state, not taken down. That includes the disable_ipv6 state. What is the state of disable_ipv6 after restart?

After restart, the device is unmanaged and the disable_ipv6 state should not change anymore.


Why do you restart NetworkManager in the first place?



Plesae in general, if possible always attach the full logfile of NetworkManager, with Debug-logging enabled. See https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf?id=ac5dc1a9510c086c54c365b1160a51cc25402010#n25
Comment 2 Jianlin Shi 2016-08-18 07:46:09 UTC 
Created attachment 1191814 [details]
NetworkManager debug log
Comment 3 Jianlin Shi 2016-08-18 07:47:37 UTC 
(In reply to Thomas Haller from comment #1)
> Hi.
> 
> On a restart, the device is left in the previous state, not taken down. That
> includes the disable_ipv6 state. What is the state of disable_ipv6 after
> restart?
> 
> After restart, the device is unmanaged and the disable_ipv6 state should not
> change anymore.

Before and After restart, disable_ipv6 is 0, only after change device name and change back, disable_ipv6 becomes 1.

> 
> 
> Why do you restart NetworkManager in the first place?
> 

Because add "NM_CONTROLLED=no" into configuration.
Comment 4 Thomas Haller 2016-08-18 14:51:05 UTC 
(In reply to Jianlin Shi from comment #3)
> (In reply to Thomas Haller from comment #1)
> > Hi.
> > 
> > On a restart, the device is left in the previous state, not taken down. That
> > includes the disable_ipv6 state. What is the state of disable_ipv6 after
> > restart?
> > 
> > After restart, the device is unmanaged and the disable_ipv6 state should not
> > change anymore.
> 
> Before and After restart, disable_ipv6 is 0, only after change device name
> and change back, disable_ipv6 becomes 1.

I tried to reproduce this, but failed to do so.

Can you please provide full debugging logs?
Which version of NetworkManager were you using?



> > Why do you restart NetworkManager in the first place?
> 
> Because add "NM_CONTROLLED=no" into configuration.

For that, it seems better to 
  $ nmcli connection load /etc/sysconfig/network-scripts/ifcfg-eth0
or 
  $ nmcli connection reload
(but of course, it valuable to test restart behavior)
Comment 5 Thomas Haller 2016-08-18 15:09:44 UTC 
(In reply to Thomas Haller from comment #4)
> Can you please provide full debugging logs?
> Which version of NetworkManager were you using?

sorry, completely missed the attached logfile. All required information present.
Thanks!
Comment 6 Thomas Haller 2017-04-24 13:15:21 UTC 
after restart, NM sees device "ens1" and treats it as unmanaged.
After renaming the device, it becomes managed -- because ifcfg-ens1 has NM_CONTROLLED=no for DEVICE=ens1. Nowhere is configured that "devname" shall be unmanaged.
As it is managed, "devname" stays in state disconnected for a while as no connection exists to activate. By adding address 192.168.1.172/24, NM creates an in-memory connection and starts "assuming" the connection, including doing DHCP.

Afterwards, the device is renamed back it is again marked as unmanaged. Which causes NM to tear down the connection, unsetting disable_ipv6 and leaving the device alone.

The wrong thing is that when NM "assumes" the connection, it should not touch the interface. For rhel-7.4, NM got better in this regard by clearly tracking such devices as "external activation".

... needs more investigation.
Comment 7 Francesco Giudici 2017-09-20 13:08:25 UTC 
Tried to reproduce on current nm-1-8 stable branch without success.
Compared attached logs with current release version (RHEL-7.4):
the main point is that the part related to assuming connections modified outside of NetworkManager has been heavily improved (big rework).
In particular, now NetworkManager correctly tracks the configuration on the device when it is renamed to "devname" without touching the connection (it is set to external) and when the device is set back to its original name, NM will not assume nor touch it.
This is not what happens on nm-1-4, as attached logs show.

So, seems to me this issue is no more present in current release (nm-1-8).
Closing the bug, please reopen if needed.
Comment 12 errata-xmlrpc 2018-04-10 13:19:11 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, 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-2018:0778
Note You need to log in before you can comment on or make changes to this bug.