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?
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
> >>> [email protected]
> >>> https://mail.gnome.org/mailman/listinfo/networkmanager-list
> >>>
> >>
> >>
> >> _______________________________________________
> >> networkmanager-list mailing list
> >> [email protected]
> >> https://mail.gnome.org/mailman/listinfo/networkmanager-list
>
>
_______________________________________________
networkmanager-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/networkmanager-list
