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
Can't reproduce this anymore. Sorry for the noise.
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.
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.
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
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?
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.
Yes, I've red that. But try setting ipv6.method to auto - it'll clear the addresses.
(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.
(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.
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.
(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
(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.
Merged branch upstream: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=3bb54e20849469eccca565b3e69a544541adcbaf
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.
(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.
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
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.
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).
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.
(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.
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
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.
This update broke IPv6 for me. See Bug 1069421 for details.
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
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.
(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).
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.
(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.
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
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.
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?
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.
(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.
Thanks. I've opened bz1119054
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.
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