GNOME Bugzilla – Bug 676740
NetworkManager fails to configure DHCPv6 address under some circumstances (because it 'assumes')
Last modified: 2012-06-06 20:59:06 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.
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 example.net {}; }; [root@router ~]# cat /etc/dhcp/dhcpd6.conf option dhcp-renewal-time 3600; option dhcp-rebinding-time 7200; subnet6 2001:abcd:1:1::/64 { option dhcp6.name-servers 2001:abcd:1:1::ef; option dhcp6.domain-search "test.test"; range6 2001:abcd:1:1::1:0000 2001:abcd:1:1::1:ffff; }
NetworkManager.conf: [main] plugins=keyfile [keyfile] unmanaged-devices=mac:52:54:00:8e:93:da Connection config: [connection] id=Test uuid=f3baee14-0320-45ca-a6b3-dec85a50a9f9 type=802-3-ethernet [ipv4] method=disabled [802-3-ethernet] mac-address=52:54:00:eb:e9:fb
Created attachment 214867 [details] NetworkManager debug Note that this debug was created with the following fix for bug 676317: http://git.pavlix.net/gitweb/?p=NetworkManager.git;a=commitdiff;h=9e9019d3ec3a4bbdbb8dd1c8b6637802fcece1a6
A fix for *this* bug can be found here: http://git.pavlix.net/gitweb/?p=NetworkManager.git;a=commitdiff;h=37e46405e06cf5bfc472a64f8bb90a78a26b738f
The fix is now part of my IPv6 branch: git://git.pavlix.net/NetworkManager ipv6
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.
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.
Thanks.