Bug 1261809 - NetworkManager removes IPv6LL address from device
NetworkManager removes IPv6LL address from device
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager (Show other bugs)
7.2
Unspecified Unspecified
high Severity medium
: rc
: 7.3
Assigned To: Beniamino Galvani
Desktop QE
:
Depends On:
Blocks: 1301628 1313485
  Show dependency treegraph
 
Reported: 2015-09-10 04:26 EDT by Vladimir Benes
Modified: 2016-05-17 05:01 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-17 05:01:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 763236 None None None 2016-03-12 09:02 EST

  None (edit)
Description Vladimir Benes 2015-09-10 04:26:05 EDT
Description of problem:
If there is an just IPv6LL address on device and NM service stopped device's IPv6LL address is removed upon NM service start.

Version-Release number of selected component (if applicable):
NetworkManager-1.0.6-2.el7.x86_64

How reproducible:
always

Steps to Reproduce:
 nmcli c del eth0               # delete existing connections on eth0
 systemctl stop NetworkManager
 ip a flush dev eth0            # delete all addresses on eth0
 ip l set eth0 down
 ip l set eth0 up               # now eth0 should have an IPv6 link-local address
 systemctl start NetworkManager

Actual results:
[root@qe-dell-ovs5-vm-5 ~]# ip  a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
    link/ether 52:54:02:2c:e1:2d brd ff:ff:ff:ff:ff:ff


Expected results:
[root@qe-dell-ovs5-vm-5 ~]# ip  a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
    link/ether 52:54:02:2c:e1:2d brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5054:2ff:fe2c:e12d/64 scope link 
       valid_lft forever preferred_lft forever


Additional info:
Comment 1 Beniamino Galvani 2015-09-11 05:04:21 EDT
I think this is a minor problem and the user can fix it by tweaking NM
configuration.

This behavior was introduced to fix bug 1138426; before the change,
when a device was found at startup having only an IPv6LL address, NM
assumed the connection and kept its configuration, ignoring other
on-disk connections for the same device.

This caused many problems because it happened frequently that users
complained that NM was not activating connections and the reason was
that the device was already up with a IPv6LL address automatically
assigned by kernel.

Now NM ignores IPv6LL configurations, takes ownership of the device
and tries to activate on-disk connections, but if there are no
available connections, the devices remains without the initial IPv6LL
address. This can be fixed by setting the device as
'assume-ipv6ll-only' in configuration, which will revert to old
behavior; or by creating a persistent connection that will be
activated.

In my opinion, we can try to be better at not interfering with
existing configuration and, for example, don't touch the interface if
we don't have candidate connections for the device.  But this requires
some bigger changes that may not be appropriate for 7.2.

My proposal is to consider this as an improvement for the next NM 1.2
release.
Comment 2 Beniamino Galvani 2015-10-28 11:44:00 EDT
After thinking longer about it, I'm convinced that the current
behavior is reasonable. Since NM is not assuming the IPv6LL-only
device and there are no candidate connections, the device goes to
DISCONNECTED state and therefore there can't be any addresses assigned
to it.

In order to keep the existing address NM has to assume the connection,
and this must be enabled explicitly in configuration with the
'assume-ipv6ll-only' option.

Vladimir, what's your opinion?
Comment 4 Beniamino Galvani 2016-01-15 07:51:37 EST
Hi Vlad,

I believe that the current behavior is acceptable for reasons explained in comment 2. In other words, either the connection gets assumed (and in that case we keep the IPv6LL address) or it doesn't (and then it will be disconnected when there aren't available connections). The behavior can be changed by the 'assume-ipv6ll-only' flag. What do you think? Thanks.
Comment 5 Beniamino Galvani 2016-03-14 03:52:11 EDT
Patch posted on upstream bz https://bugzilla.gnome.org/show_bug.cgi?id=763236
Comment 6 Mike McCune 2016-03-28 18:20:08 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 7 Beniamino Galvani 2016-04-04 08:20:55 EDT
(In reply to Beniamino Galvani from comment #5)
> Patch posted on upstream bz https://bugzilla.gnome.org/show_bug.cgi?id=763236

The upstream patch was wrong since it left the device configured while in DISCONNECTED state.
Comment 9 Beniamino Galvani 2016-05-16 05:21:58 EDT
Yeah, I think at the moment this is working as designed. Maybe we can re-think how devices are managed and assumed, but that would be a different bug (the one mentioned in comment 8). I'm for closing this. Vladimir, do you agree?
Comment 10 Vladimir Benes 2016-05-16 11:34:59 EDT
(In reply to Beniamino Galvani from comment #9)
> Yeah, I think at the moment this is working as designed. Maybe we can
> re-think how devices are managed and assumed, but that would be a different
> bug (the one mentioned in comment 8). I'm for closing this. Vladimir, do you
> agree?

Do whatever you like, I just reported suspicious behavior. If it's not buggy and there is no way to preserve IPv6LL address when assuming connection w/o touching the device then close it.
I was just expecting to preserve IPv6LL while still receiving RA in such reported scenario. Probably just corner case.

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