Bug 1368018
| Summary: | ipv6 would be disabled after change device name | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jianlin Shi <jishi> | ||||
| Component: | NetworkManager | Assignee: | Francesco Giudici <fgiudici> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 7.3 | CC: | atragler, bgalvani, jishi, lrintel, mleitner, rkhan, sukulkar, thaller, vbenes | ||||
| Target Milestone: | rc | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | nm-1.8 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2018-04-10 13:19:11 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: | 1470965 | ||||||
| Attachments: |
|
||||||
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 Created attachment 1191814 [details]
NetworkManager debug log
(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. (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) (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! 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. 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. 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 |
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