Bug 1045118 - IPv6 SLAAC addresses are added with a /128 prefix [was: IPv6 SLAAC does not work on Fedora 20]
Summary: IPv6 SLAAC addresses are added with a /128 prefix [was: IPv6 SLAAC does not ...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
(Show other bugs)
Version: 20
Hardware: Unspecified Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Thomas Haller
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On: 1056711 1057061
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-19 16:05 UTC by Simon Perreault
Modified: 2015-02-05 13:10 UTC (History)
8 users (show)

Fixed In Version: NetworkManager-0.9.9.0-30.git20131003.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-14 12:35:02 UTC
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 Bugzilla 705170 None None None Never
Red Hat Bugzilla 1044590 None None None Never

Description Simon Perreault 2013-12-19 16:05:25 UTC
Description of problem:
IPv6 fails after upgrade to Fedora 20 (from F19). It looks like a problem with processing of Router Advertisements.

Version-Release number of selected component (if applicable):
NetworkManager-0.9.9.0-20.git20131003.fc20.x86_64

How reproducible:
Reproduced on two boxes. Someone else also reported here:
https://ask.fedoraproject.org/question/36507/two-fedora-20s-loose-their-public-ipv6-address/


Steps to Reproduce:
1. Configure NetworkManager connection: in IPv6 tab, select "Method: Automatic".
2. Bring up connection on network where router sends RAs.

Actual results:
[simon@porto ~]$ ip -6 addr show dev em1 scope global
3: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2620:0:230:c000:3e97:eff:fe0b:dd8a/128 scope global dynamic 
       valid_lft 2591411sec preferred_lft 2591411sec

Expected results:
The /128 should be /64.


Additional info:
The "accept_ra" sysctl is zero. That does not look right.

[simon@porto ~]$ sudo sysctl -a | grep ipv6 | grep em1
net.ipv6.conf.em1.accept_dad = 1
net.ipv6.conf.em1.accept_ra = 0
net.ipv6.conf.em1.accept_ra_defrtr = 1
net.ipv6.conf.em1.accept_ra_pinfo = 1
net.ipv6.conf.em1.accept_ra_rt_info_max_plen = 0
net.ipv6.conf.em1.accept_ra_rtr_pref = 1
net.ipv6.conf.em1.accept_redirects = 1
net.ipv6.conf.em1.accept_source_route = 0
net.ipv6.conf.em1.autoconf = 1
net.ipv6.conf.em1.dad_transmits = 1
net.ipv6.conf.em1.disable_ipv6 = 0
net.ipv6.conf.em1.force_mld_version = 0
net.ipv6.conf.em1.force_tllao = 0
net.ipv6.conf.em1.forwarding = 0
net.ipv6.conf.em1.hop_limit = 64
net.ipv6.conf.em1.max_addresses = 16
net.ipv6.conf.em1.max_desync_factor = 600
net.ipv6.conf.em1.mc_forwarding = 0
net.ipv6.conf.em1.mtu = 1500
net.ipv6.conf.em1.ndisc_notify = 0
net.ipv6.conf.em1.optimistic_dad = 0
net.ipv6.conf.em1.proxy_ndp = 0
net.ipv6.conf.em1.regen_max_retry = 3
net.ipv6.conf.em1.router_probe_interval = 60
net.ipv6.conf.em1.router_solicitation_delay = 1
net.ipv6.conf.em1.router_solicitation_interval = 4
net.ipv6.conf.em1.router_solicitations = 3
net.ipv6.conf.em1.temp_prefered_lft = 86400
net.ipv6.conf.em1.temp_valid_lft = 604800
net.ipv6.conf.em1.use_tempaddr = 2
net.ipv6.neigh.em1.anycast_delay = 100
net.ipv6.neigh.em1.app_solicit = 0
net.ipv6.neigh.em1.base_reachable_time_ms = 30000
net.ipv6.neigh.em1.delay_first_probe_time = 5
net.ipv6.neigh.em1.gc_stale_time = 60
net.ipv6.neigh.em1.locktime = 0
net.ipv6.neigh.em1.mcast_solicit = 3
net.ipv6.neigh.em1.proxy_delay = 80
net.ipv6.neigh.em1.proxy_qlen = 64
net.ipv6.neigh.em1.retrans_time_ms = 1000
net.ipv6.neigh.em1.ucast_solicit = 3
net.ipv6.neigh.em1.unres_qlen = 31
net.ipv6.neigh.em1.unres_qlen_bytes = 65536

And here's the RA that's sent to me by the router:

[simon@porto ~]$ LANG=en sudo rdisc6 em1
Soliciting ff02::2 (ff02::2) on em1...

Hop limit                 :           64 (      0x40)
Stateful address conf.    :           No
Stateful other conf.      :           No
Router preference         :       medium
Router lifetime           :         1800 (0x00000708) seconds
Reachable time            :  unspecified (0x00000000)
Retransmit time           :  unspecified (0x00000000)
 Source link-layer address: 00:17:31:4D:F0:47
 MTU                      :         1480 bytes (valid)
 Prefix                   : 2620:0:230:c000::/64
  Valid time              :      2592000 (0x00278d00) seconds
  Pref. time              :       604800 (0x00093a80) seconds
 Recursive DNS server     : 2620:0:230:c000::65
  DNS server lifetime     :          900 (0x00000384) seconds
 from fe80::217:31ff:fe4d:f047

Comment 1 Simon Perreault 2013-12-19 18:18:06 UTC
Can't reproduce this anymore. Sorry for the noise.

Comment 2 Wolfgang Rupprecht 2013-12-21 20:28:10 UTC
I'm seeing it.  It started happening a day ago with the yum update of 2 days ago.  "ip -6 neigh show" shows only FAILED and STALE transactions.  Please reopen.  This is a real problem that requires someone to roll back a bad patch somewhere.

Comment 3 Thomas Haller 2014-01-07 10:21:26 UTC
Just for the record...

NetworkManager implements SLAAC in user-space and adds the autoconf addresses as /128. The reason why it does this, is to prevent the kernel to add a route to the whole /64 prefix, if OnLink is false.

accept_ra is set to zero be NM for the very reason, that it's not up to the kernel to handle RA.

This behaviour is present, since the beginning of NM handling RA itself.

Comment 4 Thomas Haller 2014-01-10 18:27:08 UTC
Reopening this bug.

Having /128 prefix is probably not critical and does not break networking(?). It just looks unexpected.

But it will be fixed. See upstream bug for the course of action: https://bugzilla.gnome.org/show_bug.cgi?id=705170#c5


Similar bug for RHEL7: bug 1044590

Comment 5 Paul P Komkoff Jr 2014-01-24 16:06:21 UTC
Greetings.

I've arrived here by searching "NetworkManager accept_ra", but my problem seem to be slightly different.
Before NM, I was able to set IPV6ADDR= in the config and keep auto for the router advertisements. With NM 0.9.9.0, when I set auto it autoconfigures me through SLAAC and ignores IPV6ADDR=; if I set it to manual it doesn't pick up RAs so I need to set router manually which is a little bit backwards.

Is there any way to get the semi-automatic behavior back? Any plans to fix NM, maybe? In reader.c it *looks* like it should be doing the correct thing, however it isn't.

Help?

Comment 6 Dan Williams 2014-01-24 17:21:02 UTC
The expected behavior is that both router advertisements and manual configuration should work together at the same time.  If it doesn't there's a bug and we'll fix it.

Comment 7 Paul P Komkoff Jr 2014-01-24 19:50:01 UTC
Yes, I've red that. But try setting ipv6.method to auto - it'll clear the addresses.

Comment 8 Dan Williams 2014-01-24 20:02:44 UTC
(In reply to Paul P Komkoff Jr from comment #7)
> Yes, I've red that. But try setting ipv6.method to auto - it'll clear the
> addresses.

It seems we have a bug to fix then.

Comment 9 Thomas Haller 2014-01-25 00:56:13 UTC
(In reply to Paul P Komkoff Jr from comment #7)
> Yes, I've red that. But try setting ipv6.method to auto - it'll clear the
> addresses.

AFAIS, NetworkManager (the service) allows such a configuration.

There are different clients for NetworkManager. You should mention, which client you are using. With nmcli I was able to create such a configuration. nm-applet/nm-connection-editor OTOH does not allow to set addresses together with the auto method. In principle, not all clients have to be equally powerful (requests for enhancement are welcome).

If you can detail your problem, please open a new bug.

Comment 10 Paul P Komkoff Jr 2014-01-25 15:26:30 UTC
Interesting... how exactly did you do that with nmcli?
I'll open a new bug that's for sure:

===
ipv6.method:                            auto
ipv6.dns:
ipv6.dns-search:
ipv6.addresses:
ipv6.routes:
===

set ipv6.addresses bla:bla/bla
print

(shows non-empty addresses)
save
quit

look into /etc/sysconfig/n-s/ifcfg-br0
no address I just added.

nmcli c show conf br0
no addresses

So it seems it's possible to configure, but then nm discards the configuration and drives into walls.

Comment 11 Thomas Haller 2014-01-25 18:43:03 UTC
(In reply to Paul P Komkoff Jr from comment #10)

Hi Paul,

you are right, there is an upstream commit for this, which is not backported to F20.

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=dcbw/dbus-properties&id=1a67f8df03eed7fcb6160429be48d933991c165d 

You could open a new bug, requesting to backkport this to F20 (and wait).

As a workaround, you could edit /etc/NetworkManager/NetworkManager.conf and set

[main]
    plugins=keyfile

See `man NetworkManager.conf`. This causes NM not to store the connections in /etc/sysconfig/network-scripts, but instead to use the keyfile-plugin (and save them under /etc/NetworkManager/system-connections). The keyfile plugin already supports what you want (I think -- did not test it!). The disadvantage is, that NM now uses another configuration method and you have to recreate all your connections and these connections are obviously not usable from the networking scripts (if you want to use the traditional system-config-network).


(could we move this discussion to another BZ? :) -- actually, I hope you can get it to work now. Good luck)

Thomas

Comment 12 Thomas Haller 2014-01-25 18:49:45 UTC
(In reply to Thomas Haller from comment #11)
> (In reply to Paul P Komkoff Jr from comment #10)

> See `man NetworkManager.conf`. This causes NM not to store the connections
> in /etc/sysconfig/network-scripts, but instead to use the keyfile-plugin
> (and save them under /etc/NetworkManager/system-connections). The keyfile
> plugin already supports what you want (I think -- did not test it!). The
> disadvantage is, that NM now uses another configuration method and you have
> to recreate all your connections and these connections are obviously not
> usable from the networking scripts (if you want to use the traditional
> system-config-network).

oh, actually, if you do what I said, and afterwards you change it back to 

[main]
    plugins=ifcfg-rh,keyfile

then NM will continue using /etc/sysconfig/network-scripts as preferred configuration method.

Oh, and don't forget to restart NM after changing the NetworkManager.conf.

Comment 14 Alice K 2014-01-31 09:10:12 UTC
IPv6 privacy extensions was enabled on Fedora 18 and Fedora 19 by adding the following two lines in /etc/sysctl.conf

net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2


After numerous attempts, I still could not get it to work in Fedora 20.


Adding the following line in /etc/sysconfig/network-scripts/ifcfg-*  did not work

IPV6_PRIVACY=rfc3041


Editing  /etc/NetworkManager/NetworkManager.conf  with the folling setting and a reboot did not work.  On the first reboot, the system crashed and on the second reboot, the WiFi entry was lost.  After adding a new entry and did a connection, the third random generated IPv6 Host address was not there.

[main]
    plugins=keyfile


I then did an editing with the follwing setting and it still did not work after a reboot.  The system crashed on the first reboot and a second reboot was needed.

[main]
    plugins=ifcfg-rh,keyfile


Earlier in the day, I did an update and the NetworkManager was updated.  It is  still no good.

  Updating   : 1:NetworkManager-glib-0.9.9.0-27.git20131003.fc20.x86_64                                                                 1/6 
  Updating   : 1:NetworkManager-0.9.9.0-27.git20131003.fc20.x86_64                                                                      2/6 
  Updating   : gnome-online-miners-3.10.3-1.fc20.x86_64                                                                                 3/6 
  Cleanup    : 1:NetworkManager-0.9.9.0-26.git20131003.fc20.x86_64                                                                      4/6 
  Cleanup    : 1:NetworkManager-glib-0.9.9.0-26.git20131003.fc20.x86_64                                                                 5/6 
  Cleanup    : gnome-online-miners-3.10.2-2.fc20.x86_64                                                                                 6/6 
  Verifying  : 1:NetworkManager-0.9.9.0-27.git20131003.fc20.x86_64                                                                      1/6 
  Verifying  : 1:NetworkManager-glib-0.9.9.0-27.git20131003.fc20.x86_64                                                                 2/6 
  Verifying  : gnome-online-miners-3.10.3-1.fc20.x86_64                                                                                 3/6 
  Verifying  : gnome-online-miners-3.10.2-2.fc20.x86_64                                                                                 4/6 
  Verifying  : 1:NetworkManager-glib-0.9.9.0-26.git20131003.fc20.x86_64                                                                 5/6 
  Verifying  : 1:NetworkManager-0.9.9.0-26.git20131003.fc20.x86_64                                                                      6/6 


------------------------------------------------------------------------------


Fedora 18, 19 and 20 were all basic clean install.  Fedora 20 did not have any external repository package.  I have used every Fedora distribution since Fedora 7.  NetworkManager has been a major irritant in numerous occasions, even in the early days, like the GUI did not work and the connection entries has to be edited manually a few times.  On a few occasions, a not so complicated problem took more than thee distributions or about two years to be fixed.  But then, the same bug could return.  One notable case was the broadcom WiFi driver.  From Fedora 7 to Fedora 16, I had to connect to the Wired LAN to get the WiFi packages from third party repository.  There were some hiccups in a few of the distributions and users were forced to make manual adjustments.  In Fedora 17, the WiFi works out of the box although it was not publicised.  I just make the entry in the NM and it did work and that was how I found out.  So was Fedora 18 to Fedora 20.  This was a big improvement for Fedora.  Not making any manual changes and not installing third party sotfware would ensure the quality and integrity of Fedora.  This highlight the fact that the IPv6 Privacy Extensions should work out of the box without the user manual intervention.

I could do some minor manual configuration changes by following what has been done by others like in above as I had worked in the Unix platform before.  There would be many who want to take up Fedora, but were impeded by some of the persistence problems and could not make it to work.  That is the end of the road for this group of people.

IPv6 Privacy Extensions is now a key feature.  Windows, smartphone, smartTV, blueray player and many other devices have the automatic IPv6 link-local, MAC derived host address and are connected to the internet through the random generated 64 bits global Host Address.  Hence, it is long due for Linux to build this feature into the kernel.  It should be the other way around such that IPv6 Privacy Extensions would be enabled by default and could be disabled manually.  Then the three IPv6 addresses will always be there in any Fedora Linux connection and more importantly, it would be immutable to any change that happen in NM and its regular vagaries.

I could not get IPv6 Privacy Extensions to work in Fedora 20 after making the changes by following the credible sources.  It is getting messy after a few attempts.  I will stop doing it for now.  What it the point of doing it and start all over again when it break again?  It is a waste of time at negative improvement.  For now, I will keep Fedora 18 and Fedora 19.  Fedora 20 is just there.  I am not using it at all.  Fedora 20 will be replaced with Fedora 21, Fedora 22 ... until the IPv6 Privacy Extensions is working.  Now, it is on what is the best way to do it.  That will be realm of the people who know how to do it the best way.

Comment 15 Thomas Haller 2014-01-31 12:04:46 UTC
(In reply to Alice K from comment #14)

Sorry that you got frustrated about this.

Indeed, NetworkManager 0.9.9 (as shipped with F20) does currently not support IPv6 private addresses. Meaning, you cannot get it to work, if using NM. 

Hopefully, this will be fixed very soon, that is what this bug is about.

I agree about the importance of this feature and it's taken seriously.

Comment 16 Fedora Update System 2014-02-04 23:23:51 UTC
NetworkManager-0.9.9.0-29.git20140131.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-29.git20140131.fc20

Comment 17 Thomas Haller 2014-02-04 23:34:30 UTC
For this fix, the following versions are needed:

NetworkManager-0.9.9.0-29.git20140131.fc20
libnl3-3.2.24-1.fc20
kernel-3.12.9-301.fc20


The version 0.9.9.0-27.git20140131.fc21 on Fedora 21 (rawhide) contains the change too.

Comment 18 Fedora Update System 2014-02-06 04:03:40 UTC
Package NetworkManager-0.9.9.0-29.git20140131.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing NetworkManager-0.9.9.0-29.git20140131.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-2092/NetworkManager-0.9.9.0-29.git20140131.fc20
then log in and leave karma (feedback).

Comment 19 Alice K 2014-02-07 01:37:58 UTC
I did an update just one hour ago.  It still did not work.


*** PLEASE NOTE ***

The later version is still not in the Fedora repository.  I noted that I had updated to the following.

NetworkManager-0.9.9.0-28.git20131003.fc20
kernel-3.12.9-301.fc20


I normally refrain from using the updates-testing  repository.  I will inform if my next update will work or not.


Could someone look into including the  IPv6 Privacy Extensions  included into the Linux distribution by default, like including it into the kernel without Linux users manually do anything like adding two lines into   /etc/sysctl.conf
.  This feature should work every time without failure.

Comment 20 Thomas Haller 2014-02-07 02:05:04 UTC
(In reply to Alice K from comment #19)

Indeed, you need version 0.9.9.0-29 for it to work. This version currently is still in testing. So either you wait or you install the packages as detailed in comment #19.

Comment 21 Fedora Update System 2014-02-16 15:19:48 UTC
NetworkManager-0.9.9.0-30.git20131003.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-30.git20131003.fc20

Comment 22 Fedora Update System 2014-02-22 00:59:18 UTC
NetworkManager-0.9.9.0-30.git20131003.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 23 Scott Schmit 2014-02-25 01:35:54 UTC
This update broke IPv6 for me. See Bug 1069421 for details.

Comment 24 Alice K 2014-02-27 22:52:51 UTC
In last week update to   kernel.x86_64 0:3.13.3-201.fc20   , the IPv6 Privacy Extension still did not work.


In the last update, it was finally working.  In my Fedora 20 system, no external repository was used.  All packages were native from the two normal Fedora repositories.  No test package was installed.  The following was the updated list.


Resolving Dependencies
--> Running transaction check
---> Package NetworkManager.x86_64 1:0.9.9.0-28.git20131003.fc20 will be updated
---> Package NetworkManager.x86_64 1:0.9.9.0-30.git20131003.fc20 will be an update
---> Package NetworkManager-glib.x86_64 1:0.9.9.0-28.git20131003.fc20 will be updated
---> Package NetworkManager-glib.x86_64 1:0.9.9.0-30.git20131003.fc20 will be an update
---> Package autocorr-en.noarch 1:4.1.5.3-1.fc20 will be updated
---> Package autocorr-en.noarch 1:4.2.1.1-1.fc20 will be an update
---> Package clutter.x86_64 0:1.16.2-3.fc20 will be updated
---> Package clutter.x86_64 0:1.16.2-4.fc20 will be an update
---> Package dosfstools.x86_64 0:3.0.24-1.fc20 will be updated
---> Package dosfstools.x86_64 0:3.0.25-1.fc20 will be an update
---> Package ebtables.x86_64 0:2.0.10-11.fc20 will be updated
---> Package ebtables.x86_64 0:2.0.10-12.fc20 will be an update
---> Package fedora-release.noarch 0:20-1 will be updated
---> Package fedora-release.noarch 0:20-3 will be an update
---> Package file.x86_64 0:5.14-14.fc20 will be updated
---> Package file.x86_64 0:5.14-15.fc20 will be an update
---> Package file-libs.x86_64 0:5.14-14.fc20 will be updated
---> Package file-libs.x86_64 0:5.14-15.fc20 will be an update
---> Package gnome-shell.x86_64 0:3.10.3-6.fc20 will be updated
---> Package gnome-shell.x86_64 0:3.10.3-8.fc20 will be an update
---> Package grep.x86_64 0:2.16-1.fc20 will be updated
---> Package grep.x86_64 0:2.17-1.fc20 will be an update
---> Package gssdp.x86_64 0:0.14.6-1.fc20 will be updated
---> Package gssdp.x86_64 0:0.14.7-1.fc20 will be an update
---> Package gupnp.x86_64 0:0.20.9-1.fc20 will be updated
---> Package gupnp.x86_64 0:0.20.10-1.fc20 will be an update
---> Package gupnp-av.x86_64 0:0.12.4-1.fc20 will be updated
---> Package gupnp-av.x86_64 0:0.12.5-1.fc20 will be an update
---> Package kernel.x86_64 0:3.13.4-200.fc20 will be installed
---> Package kernel-modules-extra.x86_64 0:3.13.4-200.fc20 will be installed
---> Package libcmis.x86_64 0:0.3.1-8.fc20 will be updated
---> Package libcmis.x86_64 0:0.4.1-2.fc20 will be an update
---> Package libestr.x86_64 0:0.1.5-2.fc20 will be updated
---> Package libestr.x86_64 0:0.1.9-1.fc20 will be an update
---> Package libgudev1.x86_64 0:208-9.fc20 will be updated
---> Package libgudev1.x86_64 0:208-14.fc20 will be an update
---> Package libreoffice-calc.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-calc.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-core.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-core.x86_64 1:4.2.1.1-1.fc20 will be an update
--> Processing Dependency: libfbembed.so.2.5()(64bit) for package: 1:libreoffice-core-4.2.1.1-1.fc20.x86_64
--> Processing Dependency: libeot.so.0()(64bit) for package: 1:libreoffice-core-4.2.1.1-1.fc20.x86_64
--> Processing Dependency: libGLU.so.1()(64bit) for package: 1:libreoffice-core-4.2.1.1-1.fc20.x86_64
---> Package libreoffice-draw.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-draw.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-emailmerge.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-emailmerge.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-graphicfilter.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-graphicfilter.x86_64 1:4.2.1.1-1.fc20 will be an update
--> Processing Dependency: libfreehand-0.0.so.0()(64bit) for package: 1:libreoffice-graphicfilter-4.2.1.1-1.fc20.x86_64
--> Processing Dependency: libetonyek-0.0.so.0()(64bit) for package: 1:libreoffice-graphicfilter-4.2.1.1-1.fc20.x86_64
---> Package libreoffice-impress.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-impress.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-langpack-en.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-langpack-en.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-math.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-math.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-opensymbol-fonts.noarch 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-opensymbol-fonts.noarch 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-pdfimport.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-pdfimport.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-pyuno.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-pyuno.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-ure.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-ure.x86_64 1:4.2.1.1-1.fc20 will be an update
---> Package libreoffice-writer.x86_64 1:4.1.5.3-1.fc20 will be updated
---> Package libreoffice-writer.x86_64 1:4.2.1.1-1.fc20 will be an update
--> Processing Dependency: libe-book-0.0.so.0()(64bit) for package: 1:libreoffice-writer-4.2.1.1-1.fc20.x86_64
--> Processing Dependency: libabw-0.0.so.0()(64bit) for package: 1:libreoffice-writer-4.2.1.1-1.fc20.x86_64
---> Package libreport.x86_64 0:2.1.12-2.fc20 will be updated
---> Package libreport.x86_64 0:2.1.12-3.fc20 will be an update
---> Package libreport-fedora.x86_64 0:2.1.12-2.fc20 will be updated
---> Package libreport-fedora.x86_64 0:2.1.12-3.fc20 will be an update
---> Package libreport-filesystem.x86_64 0:2.1.12-2.fc20 will be updated
---> Package libreport-filesystem.x86_64 0:2.1.12-3.fc20 will be an update
---> Package libreport-gtk.x86_64 0:2.1.12-2.fc20 will be updated
---> Package libreport-gtk.x86_64 0:2.1.12-3.fc20 will be an update
---> Package libreport-plugin-bugzilla.x86_64 0:2.1.12-2.fc20 will be updated
---> Package libreport-plugin-bugzilla.x86_64 0:2.1.12-3.fc20 will be an update
---> Package libreport-plugin-kerneloops.x86_64 0:2.1.12-2.fc20 will be updated
---> Package libreport-plugin-kerneloops.x86_64 0:2.1.12-3.fc20 will be an update
---> Package libreport-plugin-logger.x86_64 0:2.1.12-2.fc20 will be updated
---> Package libreport-plugin-logger.x86_64 0:2.1.12-3.fc20 will be an update
---> Package libreport-plugin-reportuploader.x86_64 0:2.1.12-2.fc20 will be updated
---> Package libreport-plugin-reportuploader.x86_64 0:2.1.12-3.fc20 will be an update
---> Package libreport-plugin-ureport.x86_64 0:2.1.12-2.fc20 will be updated
---> Package libreport-plugin-ureport.x86_64 0:2.1.12-3.fc20 will be an update
---> Package libreport-python.x86_64 0:2.1.12-2.fc20 will be updated
---> Package libreport-python.x86_64 0:2.1.12-3.fc20 will be an update
---> Package libreport-web.x86_64 0:2.1.12-2.fc20 will be updated
---> Package libreport-web.x86_64 0:2.1.12-3.fc20 will be an update
---> Package microcode_ctl.x86_64 2:2.1-2.fc20 will be updated
---> Package microcode_ctl.x86_64 2:2.1-3.fc20 will be an update
---> Package perl-threads.x86_64 1:1.89-1.fc20 will be updated
---> Package perl-threads.x86_64 1:1.92-1.fc20 will be an update
---> Package perl-threads-shared.x86_64 0:1.45-1.fc20 will be updated
---> Package perl-threads-shared.x86_64 0:1.46-1.fc20 will be an update
---> Package python.x86_64 0:2.7.5-10.fc20 will be updated
---> Package python.x86_64 0:2.7.5-11.fc20 will be an update
---> Package python-boto.noarch 0:2.23.0-1.fc20 will be updated
---> Package python-boto.noarch 0:2.25.0-2.fc20 will be an update
---> Package python-libs.x86_64 0:2.7.5-10.fc20 will be updated
---> Package python-libs.x86_64 0:2.7.5-11.fc20 will be an update
---> Package python3.x86_64 0:3.3.2-9.fc20 will be updated
---> Package python3.x86_64 0:3.3.2-10.fc20 will be an update
---> Package python3-libs.x86_64 0:3.3.2-9.fc20 will be updated
---> Package python3-libs.x86_64 0:3.3.2-10.fc20 will be an update
---> Package rpm.x86_64 0:4.11.2-1.fc20 will be updated
---> Package rpm.x86_64 0:4.11.2-2.fc20 will be an update
---> Package rpm-build-libs.x86_64 0:4.11.2-1.fc20 will be updated
---> Package rpm-build-libs.x86_64 0:4.11.2-2.fc20 will be an update
---> Package rpm-libs.x86_64 0:4.11.2-1.fc20 will be updated
---> Package rpm-libs.x86_64 0:4.11.2-2.fc20 will be an update
---> Package rpm-python.x86_64 0:4.11.2-1.fc20 will be updated
---> Package rpm-python.x86_64 0:4.11.2-2.fc20 will be an update
---> Package systemd.x86_64 0:208-9.fc20 will be updated
---> Package systemd.x86_64 0:208-14.fc20 will be an update
---> Package systemd-libs.x86_64 0:208-9.fc20 will be updated
---> Package systemd-libs.x86_64 0:208-14.fc20 will be an update
---> Package systemd-python.x86_64 0:208-9.fc20 will be updated
---> Package systemd-python.x86_64 0:208-14.fc20 will be an update
---> Package wavpack.x86_64 0:4.60.1-8.fc20 will be updated
---> Package wavpack.x86_64 0:4.70.0-1.fc20 will be an update
---> Package webkitgtk3.x86_64 0:2.2.4-1.fc20 will be updated
---> Package webkitgtk3.x86_64 0:2.2.5-1.fc20 will be an update
--> Running transaction check
---> Package firebird-libfbembed.x86_64 0:2.5.2.26539.0-8.fc20 will be installed
---> Package libabw.x86_64 0:0.0.2-1.fc20 will be installed
---> Package libe-book.x86_64 0:0.0.3-1.fc20 will be installed
---> Package libeot.x86_64 0:0.01-1.fc20 will be installed
---> Package libetonyek.x86_64 0:0.0.3-1.fc20 will be installed
---> Package libfreehand.x86_64 0:0.0.0-3.fc20 will be installed
---> Package mesa-libGLU.x86_64 0:9.0.0-4.fc20 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

Comment 25 Alice K 2014-02-28 00:37:38 UTC
The VPN is a useful feature in the NetworkManager.  I had been using it to connect to the external network through the Static WAN IPv4 address.  It has been working well.  Now, I am on my IPv6 network and IPv6 setup and on the ISP IPv6 infrastructure.  I can still connect remotely through the Static WAN IPv4 and the IPv4 tunnel.  The connection will failed on the Static WAN IPv4 on an IPv6 tunnel in the following illustration.  Testing has been done on Fedora 18, Fedora 19 and Fedora 20.



SUCCESSFUL CONNECTION
VPN Type: vpnc
Gateway: Static WAN IPv4 address
Group Name: ...........
Username: ...........
ROUTER: tunnel mode ipsec ipv4



FAILED TO CONNECT
VPN Type: vpnc
Gateway: Static WAN IPv4 address
Group Name: ...........
Username: ...........
ROUTER: tunnel mode ipsec ipv6



I then attempted to configure the Remote Router with a Global Unicast IPv6 address, but I failed to connect as shown in the next illustration. 


FAILED TO CONNECT
VPN Type: vpnc
Gateway: Global Unicast IPv6 address
Group Name: ...........
Username: ...........
ROUTER: Global Unicast IPv6 address
ROUTER: tunnel mode ipsec ipv6



I had noticed that navigating on two different path in both Fedora 19 and Fedora 20 have different outcomes as shown below.


Activities -> Show Applications -> Sundry -> Network Connections -> VPN -> Select VPN item and Edit

Only the IPv4 Settings is shown.  IPv6 Settings does not exist.


NetworkManager Icon -> Network Setting -> Select VPN item and Edit

It has the IPv6 Settings and the IPv4 Settings.



Anyconnect has been said to work on IPv6.  I had looked into it a few times, but I have decided to refrain in configuring the router or to use it.


As it is, although I can connect through the Static WAN IPv4 address on the IPv4 tunnel on Fedora vpnc, I have no idea whether the VPN Tunnel was working or not, now that I am fully on an IPv6 setup.


Perhaps, IPv6 vpnc on an ipsec IPv6 tunnel is an important part of the NetworkManager.  It will be a very useful Feature Set of Fedora indeed.  Can the expert in this area look into this?  Can those who are involved in or know the Fedora Feature Set process that include opening a new request, tracking the progress and formal submission for release look into this?


I am ready to do my part on my end, like Configuring the Router.  Setting up the vpnc on the NetworkManager and do the testing.  I may need some instructions to do it correctly.

Comment 26 Thomas Haller 2014-02-28 09:41:32 UTC
(In reply to Alice K from comment #25)

Hi Alice,

this doesn't relate to this bug, please open a new bug instead.

And also consider to ask in a forum or on an appropriate mailing list if you need help with configuration (contrary to bugs/defects/features for NetworkManager).

Comment 27 Alice K 2014-03-14 00:52:09 UTC
NetworkManager IPv6 Display error.


Tested in:
NetworkManager.x86_64 1:0.9.9.0-31.git20131003.fc20
kernel.x86_64 0:3.13.5-200.fc20


Occur every time.





How to reproduce:

NetworkManager Icon -> Wi-Fi -> Wi-Fi Settings -> (Select connected device)


Pop-up Window Display

Signal Strength ...
Link speed ...
Security ...

IPv4 Address  XXX.XXX.XXX.XXX

IPv6 Address  XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX   (eui-64)

Hardware Address ...
Default Route ...
DNS ...




Observations:
The NetworkManager display the  IPv6  EUI-64 address (MAC derived IPv6 address) all the time.  This is an obvious error.  How could it happen?  Why was it not spotted before release?

As a comparison, Fedora 18 and Fedora 19 NetworkManager display the IPv6 address correctly.  Fedora 18 and Fedora 19 always display the IPv6 Privacy Extensions address (Temporary IPv6 address).



Remarks:
The NetworkManager IPv6 address display error highlight the fact that the IPv6 Privacy Extensions feature is best build/handle inside the kernel.  Then the NetworkManager will just need to retrieve the system information for display rather than going its own way and do things on its one.  The NetworkManager going its separate way will always has the continuous potential to break.  It is also open to the sinister effect of using the EUI-64 address to connect to the outside world.  Then, most Fedora users are not aware of it.

Comment 28 Thomas Haller 2014-03-14 11:21:48 UTC
(In reply to Alice K from comment #27)
> NetworkManager IPv6 Display error.

This is hardly related in this bug. Please open a new bug for this issue.

Comment 29 Bill C. Riemers 2014-07-11 21:27:40 UTC
I'm not sure why this is CLOSED ERRATA.

According to the bug stack workflow:

http://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow

CLOSED ERRATA would mean this bug has been fixed and is on the stable branch.

But still even today, many months later, the privacy extensions are not working.  None of the commenters above indicated above verifying it was fixed either.  So this is not simply a case of it having been fixed and then broken again...

Bill

Comment 30 Bill C. Riemers 2014-07-11 21:34:02 UTC
Oh I see.  In comment 22 it was closed ERRATA because a new version was pushed to stable that was suppose to fix the problem.  But then the reporters for comment 23 and 24 that indicated the fix did not work failed to re-open the bug.  Thomas didn't reopen it either because he was distracted by comment 25 which is unrelated to this bug and failed to notice the previous two comments.

So it looks like there is still a problem, and nobody has been aware of it.

Comment 31 Thomas Haller 2014-07-13 14:21:32 UTC
Hi,

I think all mentioned problems of this BZ are fixed and in Fedora 20 for months now. 

Also, this BZ is not about privacy extensions. There was another bug for that. Anyway, also privacy extentions are supposed to work on Fedora 20 too.

Could you please clarify which problems are you referring to?

Comment 32 Wolfgang Rupprecht 2014-07-13 15:35:09 UTC
NM RS is still buggy after a sleep resume.   The IPv4 address is still valid, but the IPv6 address goes away and only comes back after a few minutes.  (I assume it waits till the next unsolicited RA.   NM really should speed things up by issuing an RS.

Comment 33 Thomas Haller 2014-07-13 15:47:08 UTC
(In reply to Wolfgang Rupprecht from comment #32)
> NM RS is still buggy after a sleep resume.   The IPv4 address is still
> valid, but the IPv6 address goes away and only comes back after a few
> minutes.  (I assume it waits till the next unsolicited RA.   NM really
> should speed things up by issuing an RS.

This bug is concerned with IPv6 autoconf addresses being added as /128, which is no longer the case on F20 (I updated the subject of this bug).

If you have a different problem, please open a new bug. AFAIK there is no matching bugzilla entry (yet) for the issue you are describing.

Comment 34 Wolfgang Rupprecht 2014-07-13 16:03:24 UTC
Thanks.  I've opened bz1119054

Comment 35 Bill C. Riemers 2014-07-14 12:35:02 UTC
Thomas, indeed it looks like I am posting on the wrong bug.  Sorry about the confusion.

I can confirm the SLAAC address are being correctly assigned, even for a multi-homed network.

Comment 36 Robert Muil 2015-02-05 13:10:57 UTC
For people confused as I was, this bug seems not to be directly related to the Privacy Extensions. The bug in which NetworkManager does not enable Privacy Extensions seems to be here: https://bugzilla.redhat.com/show_bug.cgi?id=1047139


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