dhcpcd-discuss

On 28/09/2017 17:30, Graham Breed wrote:
> On 28/09/17 15:14, Roy Marples wrote:
> 
>> Maybe start over with a clean slate.
>>
>> I would recommend this course of action:
>>
>>  * add `debug` to dhcpcd.conf so it's plenty verbose about what and why
>>  * add `logfile /var/log/dhcpcd.log` to dhcpcd.conf incase capturing
>>    console output is hard
>>  * start dhcpcd. I generally do `dhcpcd -dB` to force debugging and not
>>    forking to the background so I can monitor console output
>>  * one finished, post either the log file or console output here
>>    and state what you think is wrong
> 
> Okay, I've got a log attached.  This includes more than dhcpcd's output
> because it's what we already have set up.  You can see what attributes
> are being passed to the hooks.  You'll also notice that there are
> multiple dhcpcd processes running, which is an eccentricity that I don't
> think is important because I've tested on a single process for a single
> interface.

I advise sticking with dhcpcd-7.0.0-rc2 then because it has important
fixes to allow DHCPv6 when running on many interfaces.
Still, I would recommend to moving to the one daemon approach as it's
more tested and works better for sure on BSD systems at least. Linux is
more reliable, but still fragile in places. This is all in regards to
how routing is handled from conflicting sources (ie two interfaces on
the same subnet).

> 
> I can see something at the top I hadn't noticed before:
> 
> Sep 28 14:52:27 [5713]: eth1: if_disable_autolinklocal: Operation not
> supported

This means that while your Linux headers expose IN6_ADDR_GEN_MODE_NONE,
the actual kernel does not.
This basically means that your headers are much newer than your running
kernel OR you have disabled this in your kernel config. Before you ask,
I don't know what option this might be!

Nothing onerous should happen though, as it just tells the kernel not to
create any LL addresses for each interface so dhcpcd can set them itself
(ie use stable private ones rather than MAC based ones).

> Hmm.
> 
> What I think's wrong is that SLAAC addresses are being set with a /64
> but DHCPv6 addresses for apparently equivalent subnets are using /128.

There is nothing inherently wrong with this either.
When the kernel uses that address, it will use the longest matching
route on the lowest metric to route it.

So, if you have (the numbers don't make sense, just showing the idea)

deadbeef:1234:5678:5/128 as an address
deadbeef::/56 as a route
deadbeef:1234::/64 as a route  *
deadbeef:1234:9999::/64 as a route

* denotes the route the kernel will take using the address.

Metric comes into play when there are two matching routes.

Hope this helps

Roy