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
>
>> 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
>>>>
>>>>
>>
>>
--
Florian Klink
output_dhcpcd4.txt.xz
Description: application/xz
signature.asc
Description: OpenPGP digital signature
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
