Re: No IPv6 default route with dhcpcd.6.4.0-1?

On Wed, 2014-07-09 at 17:27 +0200, Florian Klink wrote:

Am 28.06.2014 00:04, schrieb Florian Klink:
Hi Dan,

Am 27.06.2014 20:40, schrieb Dan Williams:
On Fri, 2014-06-27 at 11:15 -0500, Dan Williams wrote:
On Fri, 2014-06-27 at 10:43 +0200, Florian Klink wrote:

caused by some package upgrades, (I'm quite sure it is caused by dhcpcd
upgrade from 6.3.2-1 to 6.4.0-1), I don't receive any more ipv6 default
routes from DHCPv6-enabled networks.

It suddenly stopped working in two different networks, while it still
works on other machines, and the dhcpcd upgrade was also during this time.

Arch Linux amd64
kernel 3.15.0
dhcpcd 6.4.0-1

I still receive an ipv6 address of the network, and can ping machines
inside the network.

Networkmanager log doesn't look really suspicios, I attached it anyways.

I don't see any NAK in the attached systemd journal excerpt, so
something else must cause the default to disappear/not appear at all...

Or do I need to enable some debug flags before?

The IPv6 address gets assigned and stays there. I can ping6 hosts in the
same network without problems.

I digged deeper into this. During connection, NetworkManager calls

# /usr/bin/dhcpcd -B -K -L -G -c /usr/lib/networkmanager/nm-dhcp-client.action wlp3s0
dhcpcd[7256]: version 6.4.0 starting
dhcpcd[7256]: DUID 00:01:00:01:1a:fd:69:ab:xx:xx:xx:xx:xx:xx
dhcpcd[7256]: wlp3s0: IAID a1:e4:2e:01
dhcpcd[7256]: wlp3s0: rebinding lease of
dhcpcd[7256]: wlp3s0: soliciting an IPv6 router
dhcpcd[7256]: wlp3s0: Router Advertisement from fe80::xxxx:xxxx:xxxx:xxxx
dhcpcd[7256]: wlp3s0: adding address 2002:xxxx:xxxx:0:xxxx:xxxx:xxxx:xxxx/64
dhcpcd[7256]: wlp3s0: adding route to 2002:xxxx:xxxx::/64
dhcpcd[7256]: wlp3s0: requesting DHCPv6 information
dhcpcd[7256]: wlp3s0: leased for 864000 seconds
dhcpcd[7256]: wlp3s0: adding route to
dhcpcd[7256]: wlp3s0: removing route to

With "method=auto" for IPv6, you should get an IPv6 default route set by
NetworkManager via your IPv6 default router.  Then you should also
receive a second IPv6 address from the DHCPv6 lease, but the default
route shouldn't come from dhcpcd, it should be set by NetworkManager
based on the IPv6 router advertisement.  Basically, dhcpcd shouldn't be
involved in setting the default route at all, because it doesn't have
full knowledge of the system and all the interfaces.  The logs you
posted originally don't have enough detail to see what's going on here

Could you run NM with "--log-level=debug
--log-domains=dhcp6,ip6,device,core,hw" and see what gets printed out
for IPv6 operations after "Activation (wlp3s0) Beginning IP6 addrconf."?


I disabled NetworkManagers ip handling completely:


... And started dhcpcd on my own afterwards:

dhcpcd[9996]: version 6.4.0 starting
dhcpcd[9996]: wlp3s0: adding address fe80::xxxx:xxxx:xxxx:xxxx
dhcpcd[9996]: DUID 00:01:00:01:1a:fd:69:ab:xx:xx:xx:xx:xx:xx
dhcpcd[9996]: wlp3s0: IAID a1:e4:2e:01
dhcpcd[9996]: wlp3s0: soliciting an IPv6 router
dhcpcd[9996]: wlp3s0: rebinding lease of
dhcpcd[9996]: wlp3s0: Router Advertisement from fe80::xxxx:xxxx:xxxx:xxxx
dhcpcd[9996]: wlp3s0: adding address 2002:xxxx:xxxx:0:xxxx:xxxx:xxxx:xxxx/64
dhcpcd[9996]: wlp3s0: adding route to 2002:xxxx:xxxx::/64
dhcpcd[9996]: wlp3s0: adding default route via fe80::xxxx:xxxx:xxxx:xxxx
dhcpcd[9996]: wlp3s0: requesting DHCPv6 information
dhcpcd[9996]: forked to background, child pid 10066

And as you can see, the IPv6 default route gets added!

I think the problem is the -G parameter ("Don't set any default
routes.") thats passed to dhcpcd by NetworkManager.
What do you think?


The default route actually comes from the RA, not DHCPv6.  But check
your logs for a "NAK" coming from dhcpcd.  If you see that, then I'll
bet its the same problem that I've been corresponding with a user over
IRC about.  dhcpcd touches addresses internally, and when it gets a NAK
it actually removes the IP address from the interface, which could cause
the kernel to remove the default route too.  Unfortunately, due to an
issue in NetworkManager, it is never notified of this event, and ignores
the fact that things changed, and thus doesn't restore the default

Let me know if you do see "NAK" in your logs...

If you do, please try the attached patch (for NM 0.9.8.x) and let the
NAK happen again.  If you again lose the default route, then please grab
logs from wherever your syslog daemon facility goes too.  If you're
using systemd, that'll be "journalctl -b -u NetworkManager", otherwise
it's /var/log/syslog, /var/log/messages, /var/log/daemon.log,
or /var/log/NetworkManager.log depending on your distro.


networkmanager-list mailing list
networkmanager-list gnome org

networkmanager-list mailing list
networkmanager-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]