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