Bug 1008104

It might help if you attach the logs showing the whole connection activation attempt.
Also, can you list the details of the connection you are activating:
$ nmcli con show conf "name of your connection"

Created attachment 800802 [details]
journalctl -b -u NetworkManager

Here's journalctl -b -u NetworkManager, let me know if you would like any more/further.

The problematic lines are:
Sep 20 17:15:00 jelerak.scrye.com NetworkManager[1040]: <error> [1379718900.433122] [rdisc/nm-lndp-rdisc.c:184] send_rs(): (wlp3s0): cannot send router solicitation: -99.
and
Sep 20 17:15:17 jelerak.scrye.com NetworkManager[1040]: refresh_object: assertion 'kernel_object' failed

-99 is an errno meaning:
#define EADDRNOTAVAIL   99      /* Cannot assign requested address */

It would help if you can switch on DEBUG mode for NM, so that we can see more verbose logs:
$ sudo nmcli g l level DEBUG
and when you are done, set back to normal
$ sudo nmcli g l level INFO

Please grab the output of
$ nmcli con show conf antidisestablishmentarianism

What are the versions of kernel and libnl3 ?

Created attachment 802432 [details]
debug enabled logs

Here's the logs after a boot where I set debugging.

Created attachment 802433 [details]
nmcli con show conf antidisestablishmentarianism

kernel-3.12.0-0.rc2.git0.1.fc21.x86_64
libnl3-3.2.22-2.fc21.x86_64

I ran across somebody on IRC the other day with this same problem.  It turned out his radvd options were the culprit, I think:

(12:49:09 PM) prahal: dcbw: sorted out the issue from yesterday thanks to your debug patch . On the radvd box I add prefix <...>::1/64 (ending up as needle) instead of prefix <...>::/64 (which was what was in the haystack), thanks

The problem is that the NDP-calculated route that NetworkManager adds to the kernel gets changed somehow by the kernel or libnl3, and thus after adding the route when NetworkManager asks the kernel for the version the kernel is actually using, they don't match (the refresh_object() problem).

Could people with this problem check what their IPv6 router is actually broadcasting for a prefix?

Bingo. Exactly the problem here. ;) 

ipv6 now works fine with the new NM. 

i am getting "Could not start connection: wrong plugin state 3" from my vpn plugins now, but thats a seperate issue. ;)

(In reply to Kevin Fenzi from comment #8)
> Bingo. Exactly the problem here. ;) 
> 
> ipv6 now works fine with the new NM. 

Excellent, nice to know, I think I'll keep this bug open though as it appears that people are hitting it pretty often.  It's odd that radvd doesn't appear to care about a supposedly invalid configuration.

> i am getting "Could not start connection: wrong plugin state 3" from my vpn
> plugins now, but thats a seperate issue. ;)

That's something we screwed up recently and subsequently fixed upstream, see https://bugzilla.gnome.org/show_bug.cgi?id=708255 .

Pavel, any thoughts on this?  Can we somehow fix this up in the platform so that we match whatever fixup the kernel is doing?

Could it be that in src/rdisc/nm-lndp-rdisc.c here:

		/* Device route */
		memset (&route, 0, sizeof (route));
--->		route.network = *ndp_msg_opt_prefix (msg, offset);
		route.plen = ndp_msg_opt_prefix_len (msg, offset);
		route.timestamp = now;

NetworkManager needs to mask off the lower <prefix> bits to ensure that mis-configured prefixes are fixed up to only represent the network bits?

(In reply to Dan Williams from comment #10)
> Pavel, any thoughts on this?  Can we somehow fix this up in the platform so
> that we match whatever fixup the kernel is doing?
> 
> Could it be that in src/rdisc/nm-lndp-rdisc.c here:
> 
> 		/* Device route */
> 		memset (&route, 0, sizeof (route));
> --->		route.network = *ndp_msg_opt_prefix (msg, offset);
> 		route.plen = ndp_msg_opt_prefix_len (msg, offset);
> 		route.timestamp = now;
> 
> NetworkManager needs to mask off the lower <prefix> bits to ensure that
> mis-configured prefixes are fixed up to only represent the network bits?

I'm ok with masking off the route network right in the nm-lndp-rdisc code and possibly adding a simple check to nm-platform.

Pavel, any chance you could do a patch for that?

(In reply to Dan Williams from comment #12)
> Pavel, any chance you could do a patch for that?

Started an upstream bug. I'll prepare a patch but I don't yet know when. Assiging to myself as it's a Fedora bug and I'll be working on the solution.

For reference: the upstream bug is https://bugzilla.gnome.org/show_bug.cgi?id=709230

(In reply to Thomas Haller from comment #14)
> For reference: the upstream bug is
> https://bugzilla.gnome.org/show_bug.cgi?id=709230

It's actually in the 'External Trackers' section at the top of this bugzilla page.

Upstream branch dcbw/rh1008104-bgo709230-rdisc-prefix-mask for review.

NetworkManager-0.9.9.0-14.git20131003.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-14.git20131003.fc20

Package NetworkManager-0.9.9.0-14.git20131003.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-14.git20131003.fc20'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-18316/NetworkManager-0.9.9.0-14.git20131003.fc20
then log in and leave karma (feedback).

NetworkManager-0.9.9.0-14.git20131003.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.