GNOME.org
 

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

Am 10.07.2014 um 23:48 schrieb Florian Klink:

Am 10.07.2014 23:19, schrieb Dan Williams:

On Thu, 2014-07-10 at 22:11 +0200, Florian Klink wrote:

Am 10.07.2014 21:09, schrieb Dan Williams:

On Thu, 2014-07-10 at 20:40 +0200, Florian Klink wrote:

Hi,
Am 10.07.2014 18:26, schrieb Dan Williams:

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

Hi,

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:

Hi,

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
networkmanager 0.9.8.10-3
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 172.23.100.20
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 172.23.100.20 for 864000 seconds
dhcpcd[7256]: wlp3s0: adding route to 172.23.0.0/17
dhcpcd[7256]: wlp3s0: removing route to 172.23.0.0/17


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
though.

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."?

Thanks!
Dan


I ran NetworkManager with the parameters described and attached the log.
ipv6 method was set to auto.

Seems like I received two IPv6 prefixes this time (as the dialup router
recently changed its IPv6 prefix), but there's still no IPv6 default
route coming through...


Thanks.  The logs indicate that the kernel is *not* using the prefix
information from the Router Advertisement for some reason.  This is
usually legitimate, like the RA has no prefix information at all, or
it's not correctly formed.  The RA does specify "otherconf" though,
which is why dhcpcd starts DHCPv6 and gets an address.

Unfortunately, AFAICT, the behavior that dhcpcd has is not standards
compliant, for two reason:

1) the router advertisement only includes the "OtherConf" option:

device_set_ra_flags(): (wlp3s0) IP6 device ra_flags: 0x00000000  () ->
0x80000080  (O)

which indicates that no DHCPv6 addressing should be performed, only DNS
servers and domain information should be retrieved.

2) DHCPv6 is not a mechanism to deliver the default route, and dhcpcd
should not be adding a default route via the DHCP server.  The only way
to deliver default routes correctly with IPv6 is through the Router
Advertisement with a Prefix Information option.

It seems that the router you have does not wish to provide global IPv6
connectivity for you, since (a) it only sets "OtherConf" and (b) does
not include a Prefix Information option.  Do you actually get global
IPv6 connectivity with the address + default route that dhcpcd assigns?

Also, could you run "wireshark" to capture the router advertisement so
we can confirm this?


I ran wireshark and managed to capture the Router Advertisement Package.
I attached it to this mail.


Excellent.  It shows that the RA *does* include the Prefix Information
option, and it initially looks like a well-formed RA.  Note that it
includes two prefixes:

2a02:3100:6e0a:1d00::/64
fd00::/64

and also sends DNS servers and static routes.  So unless the DHCP server
sends some other information, you don't even need to run DHCP to receive
your addresses.

So the next question is if the kernel would be doing the right thing
with the RA, but dhcpcd is interfering with it.  Could you do something
like the following (which effectively duplicates what NM 0.9.8.10 does):

1) move dhcpcd to dhcpcd.orig
2) create a script called 'dhcpcd' that contains:

#!/bin/bash
dhcpcd.orig -4 $@

to ensure that IPv6 is disabled.  Then run NM with debug output again as
before and lets see if the kernel picks up the RA information.

Dan



Seems like we're getting somewhere :-)

I created the wrapper as described, however it seems like NM doesn't
like something with a non-IPv6-aware dhcpcd, as the connection never
gets finished completely. I do however see some router advertisements
now handled by the kernel (?) in NMs log...


During connection setup, I see routes for fe80::/64, a gateway route via
the fe80:... router address, and a route for the /64 global subnet.
However, I only do have an ip address in the fe80::/64 space, not in the
global /64 space.

I attached NM's output again.

Florian


Hi,

just wanted to let you know that the problem is fixed again with

- dhcpcd-6.4.3-1
- networkmanager-0.9.10.0-2
- linux-3.16.0-2-ARCH

Don't know which upgrade fixed it though.

Florian







I do get global IPv6 connectivity by adding a route like

ip -6 r add default via $prefix_without_netmask dev wlp3s0



On a second run, after killing NetworkManagers' dhcpcd and invoking my
own manually, the incoming package looked exactly the same, except the 2
bytes starting from 0x000c to 0x000d (which seem to be always different).

when manually run, dhcpcd added the above default route automatically:


dhcpcd[24034]: wlp3s0: adding route to 2a02:3100:6e0a:1d00::/64


... and I had global connectivity.


Florian




Thanks,
Dan


Florian







I disabled NetworkManagers ip handling completely:

[ipv4]
method=link-local
ignore-auto-routes=true
ignore-auto-dns=true

[ipv6]
method=link-local
ignore-auto-routes=true
ignore-auto-dns=true



... 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 172.23.100.20
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?

Florian







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
route.

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.

Thanks!
Dan






_______________________________________________
networkmanager-list mailing list
networkmanager-list gnome org
https://mail.gnome.org/mailman/listinfo/networkmanager-list




_______________________________________________
networkmanager-list mailing list
networkmanager-list gnome org
https://mail.gnome.org/mailman/listinfo/networkmanager-list











_______________________________________________
networkmanager-list mailing list
networkmanager-list gnome org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]