GNOME Bugzilla – Bug 641333
Broken IPv6 default route (no gateway)
Last modified: 2011-04-04 17:25:11 UTC
This is a copy of the Ubuntu bugreport at https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/704812 . When setting IPv6 to "Automatic" instead of "ignore" network-manager 0.8.3+git.20101219t181118.e919218-0ubuntu1 creates an IPv6 default route pointing to the interface, but it has no gateway set. This means the kernel will look for all global destinations directly on the ethernet using Neighbor Solicitation and will fail after 3 seconds of timeout. You must never ever create a default route to a non-pointtopoint interface. In automatic mode you don't have to create a route at all, as the kernel will learn it from the Router Advertisements. I'm not really familiar with the code, but I haven't found anything that suggests a change in this behaviour in the git history. So the bug is probably still there with the current master.
See the launchpad bug for additional and a logfile. 1) Set IPv6 to auto instead of ignore 2) connect to a (wireless?) network where IPv6 RA works fine (the client gets an autoconfed address and route), but DHCPv4 fails to answer in time (shutdown the server) 3) after DHCPv4 timeout nm disconnects 4) reconnect to the same network using nm-applet 5) this time make sure DHCPv4 works (start the server again) 6) on successful connect you have two IPv6 default routes, one pointing to the LL next-hop from RA (correct) and one pointing to the interface without nexthop (wrong) It does not happen when a) the first connection attempt already succeeded b) IPv6 is set to ignore in the connection profile Since nm is still not flushing the IPv6 address when the interface goes down I assume it is recording the list of routes present before step 4 (which includes the correct nexthop to the router) and attempts to readd them after step 5, but fails to set the next hop correctly. Interesting side effect, I have to delete the wrong route three times before it is finally gone. It looks like nm is readding it immediately, but I don't see anything in the debug log. I could not find the debug category where it shows adding routes at all.
I think I know what's going on here. NM code in nm_device_deactivate() is checking whether there's an IPV6 config before flushing IPv6 routes. But when configuration fails (as in your log's DHCPv6 run) then there won't be an IPv6 config, and thus NM doesn't flush those routes. The fix is to flush IPv6 routes both if we tried IPv6 (and failed) *and* if IPv6 succeeded. Side note: your network's Router Advertisements indicate that DHCPv6 should be used to request additional information. That request fails, which terminates the IPv6 configuration attempt. Are you sure your network is configured correctly? If so, are you sure your firewall is allowing DHCPv6 packets? Should be fixed with these commits, any chance you can test them? e050f44ab6b0464d5436217ec21ba99b3afb6156 (master) 36ef4a2212c19c810d774978cf6d725f92b52e4f (0.8.x) Thanks!
Looks good to me. I cannot test it at the university atm, but I tried it at home disabling my IPv4 DHCP server on the first try and the broken route is not there. Thanks a lot. Bernhard
*** Bug 646703 has been marked as a duplicate of this bug. ***
Dan, I think #646703 is a duplicate of #643414, not #641333. This one has beeen fixed, but the issue Gavin and me have been reporting has not.