After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 741489 - NM sometimes eats externally configured IPv6 addresses
NM sometimes eats externally configured IPv6 addresses
Status: RESOLVED DUPLICATE of bug 740702
Product: NetworkManager
Classification: Platform
Component: IP and DNS config
git master
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-12-13 20:14 UTC by Mantas Mikulėnas (grawity)
Modified: 2014-12-14 17:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Mantas Mikulėnas (grawity) 2014-12-13 20:14:51 UTC
I have an externally managed (i.e. not NM-managed) OpenVPN connection which sets up a 'tap' device, then configures a few IPv4 and IPv6 addresses and routes. (It does so using regular `ip addr add` and `ip route add` commands.)

Without NM, everything works fine, `ip -6 monitor` shows:

[begin]

42: tap-sky    inet 169.254.0.2/16 scope link tap-sky
       valid_lft forever preferred_lft forever
42: tap-sky    inet 62.113.218.236/32 scope global tap-sky
       valid_lft forever preferred_lft forever
42: tap-sky    inet6 fe80::28e7:21ff:fe15:c345/64 scope link 
       valid_lft forever preferred_lft forever
42: tap-sky    inet6 2a00:f48:1029::1:7ae1:85b3/128 scope global noprefixroute 
       valid_lft forever preferred_lft forever

[end]

However, with NM active, the IPv4 address is added just fine but the IPv6 one never appears; in fact, `ip monitor` shows it getting deleted but never added:

[begin]

45: tap-sky    inet 169.254.0.2/16 scope link tap-sky
       valid_lft forever preferred_lft forever
45: tap-sky    inet 62.113.218.236/32 scope global tap-sky
       valid_lft forever preferred_lft forever
Deleted 45: tap-sky    inet6 2a00:f48:1029::1:7ae1:85b3/128 scope global tentative noprefixroute 
       valid_lft forever preferred_lft forever
Deleted 45: tap-sky    inet6 fe80::649a:67ff:fef5:b86a/64 scope link tentative 
       valid_lft forever preferred_lft forever
45: tap-sky    inet 169.254.0.2/16 scope link tap-sky
       valid_lft forever preferred_lft forever
45: tap-sky    inet 62.113.218.236/32 scope global tap-sky
       valid_lft forever preferred_lft forever
45: tap-sky    inet6 fe80::649a:67ff:fef5:b86a/64 scope link 
       valid_lft forever preferred_lft forever

[end]

Oddly, NM's own log does not show the 2a00 address being added either.

It does, however, show:

<debug> [1418500989.990221] [platform/nm-linux-platform.c:2052] _log_dbg_sysctl_set_impl(): sysctl: setting '/proc/sys/net/ipv6/conf/tap-sky/disable_ipv6' to '1' (current value is '0')
<debug> [1418500989.990787] [platform/nm-linux-platform.c:2052] _log_dbg_sysctl_set_impl(): sysctl: setting '/proc/sys/net/ipv6/conf/tap-sky/disable_ipv6' to '0' (current value is '1')

I assume that this is what causes all IPv6 addresses to be removed.

(I see that ipv6.method defaults to 'ignored'. But if I change it using `nmcli`, NM ignores that and generates a fresh connection the next time I start the VPN. So that doesn't help.)

NetworkManager 1.1.0 (g471375a)
Linux 3.17.6-1-ARCH
Comment 1 Thomas Haller 2014-12-14 17:55:20 UTC
I close this bug as duplicate of bug 740702. I think it's the same issue.

Of course, if you disagree, feel free to reopen.
And feel invited, to comment on the other bug.

Thank you

*** This bug has been marked as a duplicate of bug 740702 ***