dhcpcd-discuss

On 19/01/2014 1:11, Mike Kazantsev wrote:
> Yeah, it kinda works...
>
> Resulting configuration (/etc/dhcpcd.myisp.conf) I have is:
>
>   duid
>   persistent
>   option rapid_commit, classless_static_routes
>   require dhcp_server_identifier
>   nohook resolv.conf, lookup-hostname, hostname, ntp.conf, yp.conf
>   noipv4ll
>
>   vendorclassid dhcpcd:Linux-3.X.X:x86_64
>   vendclass 40712 dhcpcd:Linux-3.X.X:x86_64
>
>   noipv6rs
>
>   waitip 46
>   timeout 10
>
>   #debug
>
>   interface ext1
>    iaid b9:86:f4:39
>    ia_pd b9:86:f4:39 enp1s0/0/56
>
>   interface enp1s0
>    noipv4
>    noipv6
>
> And running dhcpcd as:
>
>   dhcpcd -f /etc/dhcpcd.myisp.conf --nogateway ext1 enp1s0
>
> Works nicely with two existing IPv6 and IPv4 on enp1s0 - didn't think
> about these "noipv4" options in that context before seeing you add 
> these
> to docs for similar example case.
>
>
> dhcpcd waits for both IPv4 and IPv6, assigning delegated range to
> enp1s0, but with some extra interesting output:
>
>   dhcpcd[3394]: DUID 00:01:00:01:1a:17:60:58:1c:bd:b9:86:f4:39
>   dhcpcd[3394]: enp1s0: IAID bc:dc:af:42
>   dhcpcd[3394]: ext1: IAID b9:86:f4:39
>   dhcpcd[3394]: ext1: soliciting an IPv6 router
>   dhcpcd[3394]: ext1: ipv6nd_sendrsprobe: sendmsg: Cannot assign
> requested address
>   dhcpcd[3394]: ext1: confirming Prefix Delegation
>   ...
>
> I thought "noipv6rs" (which I have in the config globally) was supposed
> to disable whole router solicitation mechanism?

It is.
With your exact configuration and command line syntax I cannot replicate 
the above using my latest code.

> It is explicitly mentioned as "to disable" thing for ia_pd (and I guess
> it's also an obvious thing related to RFCs which I just don't know), so
> assume that hint is there so that RS requests won't get sent anywhere
> but on ia_pd-context interface, where they get implicitly (and
> forcefully) enabled.
>
> If so, maybe that's the thing worth mentioning that reasoning and
> implicit RS being always enabled where IA_PD is?

I don't recall why I said you should disablle ipv6rs when doing pd.
When I remember, I'll document it!

> And the "ipv6nd_sendrsprobe: sendmsg: Cannot assign requested address"
> seem to be common to everywhere I use dhcpcd (e.g. also in wicd logs,
> which runs dhcpcd on wifi links) and easily googleable elsewhere.

I know why it happens.
Coming up, the interface will be assigned a Local Link address with have 
the TENTATIVE state until the kernel has worked out it can be used 
safely.
If this flag is set, the address itself cannot be used, which is the 
error you are seeing.
Sadly, Linux lacks an ioctl to get the address flags while enumerating 
them. If you used a BSD you would not see this error (but you would see 
others, heh).

This is fixable I think though, we can send a RTM_GETADDR netlink 
message and see what we get back.

> ipv6ra_own parameter doesn't seem to have effect on the thing, except
> added "dhcpcd[6102]:  <ifname>: disabling Kernel IPv6 RA support"
> messages.

Well, the parameter makes dhcpcd assign addresses and routes from the RA 
instead of the kernel.

> And then also the whole thing with IA_PD doesn't actually work -
> assigned IPv6 on enp1s0 is "2a02:17d0:3b0:a500:7271:bcff:fedc:af42/56"
> and doing "ping6 google.com", tcpdump sees icmp6 packets going towards
> google from ext1 (so forwarding works, egress not blocked here), but no
> replies seen on ext1.
>
> IA_NA used to give me 2a02:17d0:200:d518::1/128, and assigning that to
> ext1 manually gets linux using it to send pings from instead (by
> default), and ISP replies to that just fine.
>
> ISP also actually routes packets from Hurricane Electric (6to4 broker)
> IPv6, when they exit from ext1, and I see replies to these on SIT
> tunnel... looks like the only thing they don't route is IA_PD they hand
> out here ;)
>
> Fairly sure it has nothing to do with dhcpcd and either my fault or ISP
> issue, which I'll probably figure out with them.

Doesn't sound like a dhcpcd issue.

> Just wanted to mention to be completely honest wrt that "So you're all
> up and running fine now?" question ;)
>
>
> Apologies for such ultra-long message - got carried away a bit, can
> probably do tl;dr, if necessary/incomprehensive/too-much-rambling.

No problem.
Apologies for my terse replies, I tend to keep things short and to the 
point ;)

Roy