Bug 797524 - [0.9.2-1 regression] IPv6 mode auto immediately fails the connection after activation
Summary: [0.9.2-1 regression] IPv6 mode auto immediately fails the connection after ac...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 16
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-26 13:23 UTC by Tore Anderson
Modified: 2013-02-13 13:53 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-13 13:53:16 UTC
Type: ---


Attachments (Terms of Use)
debug-level syslog from failed connection attempt (68.93 KB, text/plain)
2012-02-26 13:23 UTC, Tore Anderson
no flags Details

Description Tore Anderson 2012-02-26 13:23:10 UTC
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.

Comment 1 Tore Anderson 2012-02-29 15:50:16 UTC
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

Comment 2 Dan Williams 2012-03-07 21:27:34 UTC
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.

Comment 3 Frank Crawford 2012-03-25 11:16:30 UTC
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?

Comment 4 Trever Adams 2012-04-02 15:40:12 UTC
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.

Comment 5 Trever Adams 2012-09-12 13:12:39 UTC
Has this been fixed? I can't remember if I have a workaround in place or not.

Comment 6 Fedora End Of Life 2013-01-16 13:11:26 UTC
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

Comment 7 Fedora End Of Life 2013-02-13 13:53:18 UTC
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.


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