Created attachment 565891 [details] debug-level syslog from failed connection attempt Description of problem: When attempting to activate a network connection using IPv6 mode Automatic, it will succeed (addresses and routing are added to the kernel, and nameservers are added to /etc/resolv.conf), and for a split second everything is fine, but immediately after successfully activating the connection, it transitions from "activated" to "failed" with reason "ip-config-unavailable". This problem did not occur in the previous NM version (0.9.1.90-5.git20110927), so this is a regression. Version-Release number of selected component (if applicable): NetworkManager-0.9.2-1.fc16.x86_64 How reproducible: 100% Steps to Reproduce: 1. Attempt to connect to an IPv6-enabled network using IPv6 mode Automatic Actual results: The connection succeeds, but is failed immediately afterwards. Expected results: The connection should stay up, as it does with NM 0.9.1.90-5.git20110927. Additional info: My network is using SLAAC for addressing/routing and stateless/information-only DHCPv6 to learn DNS servers (OtherConfig=1 in RA). The problem occurs regardless of what the IPv4 mode is set to. This means that the bug makes NM incapable of successfully activating a connection to a dual-stacked IPv4+IPv6 network, as the IPv6 failure results in the IPv4 connectivity being torn down as well. I have therefore set the severity of this bug to "high". I am attaching a debug-level snippet from /var/log/messages from such a failed connection attempt. I can easily provide a similar log of a working activation from 0.9.1.90-5.git20110927, if that would help. I set the IPv4 mode to "disabled" when producing the log, in order to minimise the amount of messages not relevant to the bug.
FYI: I have attempted to reproduce this problem using NetworkManager-0.9.3-0.2.git20120215 rebuilt on F16, but it seems to be fixed there. Tore
Looks like the issue is that the RA address 2001:840:3035:0:230:1bff:febc:7f23/64 gets removed by NM after DHCP is complete. I can't see a good reason in the old code why NM would replace the IP6 config from RA with the one from DHCP, but I'm pretty sure it's fixed in latest bits with the new parallel v4/v6 stuff. At some point here we'll be rebuilding F17's NM for F16; v 0.9.4.
With the release of Linux 3.3 kernel RPM for F16, this issue looks like it will hit all IPv6 installations soon. Details can be found in bzr 785772. Any ideas about when an F16 update for NetworkManager will occur?
I am seeing this FC16 and FC17, wired and wireless. I also am using IPv6. I see several messages like: [ 1432.900536] ICMPv6 RA: ndisc_router_discovery() failed to add default route. [ 1515.639377] ICMPv6 RA: ndisc_router_discovery() failed to add default route. After several of these, instead of short up/down on the link, the link goes down for 20-30 seconds. This has been bothering me for a few weeks now.
Has this been fixed? I can't remember if I have a workaround in place or not.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.