After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 676740 - NetworkManager fails to configure DHCPv6 address under some circumstances (because it 'assumes')
NetworkManager fails to configure DHCPv6 address under some circumstances (be...
Product: NetworkManager
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Reported: 2012-05-24 14:03 UTC by Pavel Simerda
Modified: 2012-06-06 20:59 UTC
See Also:
GNOME target: ---
GNOME version: ---

NetworkManager debug (60.69 KB, text/x-log)
2012-05-24 14:13 UTC, Pavel Simerda

Description Pavel Simerda 2012-05-24 14:03:23 UTC
I hope it is well reproducable. Steps:

1) Disable all other interfaces in NetworkManager (will attach config)

2) Disable IPv4 on this interface (will attach config)

3) Configure radvd and DHCPv6 on the network (will attach configs)

4) Make sure that device is down (ip link)

5) Make sure device has no addresses (ip address)

6) Start NetworkManager with debugging

/path/to//NetworkManager --no-daemon --log-level=DEBUG
  --log-domains=IP4,IP6,DHCP6,DEVICE 2>nm.log

7) Wait a while

8) Find the global IPv6 address in the debug

NetworkManager learns its IPv6 address, it just does not use it!

9) Check that there is a line (it will usually be the last one):

NetworkManager[30104]: <debug> [1337867610.707001] [nm-ip6-manager.c:571] check_addrconf_complete(): (eth1): dhcp_opts checked (state got-ra)

(unfortunately, this seems to depend on resolution of bug 676317)

10) Check that *no* global IPv6 address is assigned

You're done. Configuration, logs and a proposed solution will be attached.
Comment 1 Pavel Simerda 2012-05-24 14:04:52 UTC
On the router:

[root@router ~]# cat /etc/radvd.conf
interface eth1
	AdvSendAdvert on;
	MinRtrAdvInterval 30;
	MaxRtrAdvInterval 100;
	AdvManagedFlag on;
	AdvOtherConfigFlag on;
	prefix 2001:abcd:1:1:0::/64
		AdvAutonomous off;
	#RDNSS 2001:abcd:1:1::ab {};
	#DNSSL {};

[root@router ~]# cat /etc/dhcp/dhcpd6.conf 
option dhcp-renewal-time 3600;
option dhcp-rebinding-time 7200;

subnet6 2001:abcd:1:1::/64 {
	option 2001:abcd:1:1::ef;
	option dhcp6.domain-search "test.test";
	range6 2001:abcd:1:1::1:0000 2001:abcd:1:1::1:ffff;
Comment 2 Pavel Simerda 2012-05-24 14:06:03 UTC


Connection config:



Comment 3 Pavel Simerda 2012-05-24 14:13:57 UTC
Created attachment 214867 [details]
NetworkManager debug

Note that this debug was created with the following fix for bug 676317:;a=commitdiff;h=9e9019d3ec3a4bbdbb8dd1c8b6637802fcece1a6
Comment 4 Pavel Simerda 2012-05-24 14:18:04 UTC
A fix for *this* bug can be found here:;a=commitdiff;h=37e46405e06cf5bfc472a64f8bb90a78a26b738f
Comment 5 Pavel Simerda 2012-05-24 17:02:56 UTC
The fix is now part of my IPv6 branch:

git:// ipv6
Comment 6 Dan Williams 2012-05-31 20:34:17 UTC
I'm pretty sure we dont' have all the code here for IPv6 connection assumption yet.  Here's what that process should look like, when NM starts:

1) Is the device up, and does it have an IPv6 address?
   - no: nothing to take over, manage as usual
   - yes: proceed
2) does the IPv6 config on the interface match an IPv6 config from a connection we know about?
   - no: tear the device down and manage as usual
   - yes: proceed
3) if the config allows DHCP, does dhclient have a recorded lease for one of the IPv6 addresses on the interface?
   - no: tear the device down and manage as usual
   - yes: yay! copy the existing IPv6 config and jump to activation stage 3

Basically, if the device's IP config matches something we know about, and (if DHCP is allowed in that connection) DHCP has a lease for the address, we take the device over without touching it.

With IPv6 there are of course some complications; after finding an applicable connection we should kill a running dhclient for the interface without releasing the lease, respawn a new one (to make sure we have the right PID and that it's calling our dhclient-script) which will renew the lease.  If we're in OtherConfig then of course we just do that to get DNS information and such.  We should also try to grab the RDNSS and DNSSL stuff from the last RA if we can.
Comment 7 Pavel Simerda 2012-06-02 02:25:04 UTC
Well then, we can either keep this bug report after push to master, or we can copy your comment to a separate bugreport. Thanks for clarification.
Comment 8 Pavel Simerda 2012-06-06 20:59:06 UTC