dhcpcd-discuss

Hi Philipp

On 23/01/2017 08:55, Philipp Gesang wrote:
> Hi Roy,
> 
> thanks for your reply. Sorry for not answering sooner, I was out
> of office for a week.
> 
> -<| Quoting Roy Marples <roy@xxxxxxxxxxxx>, on Sunday, 2017-01-15 14:24:41 |>-
>> Hi Philipp
>>
>> Regarding ticket 5e9661e84e, you said:
>>> dhcpcd will still remove addresses from other interfaces than eth8
>>> if they clash with a lease. This is contrary to documented behavior
>>> according to which dhcpcd will not touch other interfaces unless
>>> running as master.
>>
>> I don't see this in dhcpcd documentation, all I have this this in dhcpcd(8):
>>  If a list of interfaces are given on the command line, then dhcpcd only
>> works with those interfaces, otherwise dhcpcd discovers avail‐
>>      able Ethernet interfaces that can be configured.
>>
>> That does not imply that other interfaces will not be touched to achieve
>> the desired result on the interface dhcpcd is running on.
> 
> Understood.
> 
>> As you even went out of your way to supply a patch, it implies this is a
>> behavior you want. This is not the way dhcpcd has been designed (it's
>> been designed to share the same IP on different interfaces and only have
>> one "active"), so it's probably best to move it to a new option.
> 
> Sounds reasonable. (Though you might run out of option bits in
> the process.)

I'm painfully aware I'm near the limit .....

> To supply a little context: For my purposes I need dhcpcd to work
> 
>   a) only on the nic specified, and
>   b) to not configure even that nic.
> 
> a) is the core of the ticket at hand; b) hasn’t come up yet but
> it is essential nonetheless. I have a draft patch ready that adds
> a “--noconfigure” option for b).
> 
> The point of all this is that our system does its own link
> management. The role of dhcpcd is to talk to DHCP servers and
> then pass on the information through the script callback (which
> in our case is a binary communicating with the management engine
> via custom IPC). The final decision as to whether a lease, the
> gateways, static routes etc. are acceptable cannot be made by
> dhcpcd because it has no idea about the rest of the system and
> whether inconsistencies might arise elsewhere.

That's fair enough.

> I’ll attach the working draft of the patch for b). Note that I
> lack familiarity with dhcpcd’s code base so this is likely to be
> incomplete. My tests were mainly performed by sniffing Netlink
> for events caused by dhcpcd: With the patch applied it is all
> silent which is exactly what I need.

It is incomplete - there are no IPv6 alterations nor man page adjustments.

Also, you may wish to consider that dhcpcd may adjust sysctl values to
suit (for example disabling IPv6 RA handling in the kernel). I don't
know how that affects your use case.

> I hope I could elucidate the purpose of the patch. Let me know
> what you think about it. I’ve also subscribed to the mailing list
> so I you prefer we can continue there.

One issue with this is that (for DHCPv4 at least) some operations
require UNICAST which requires the IP address to be active.
If the IP address is not present, RENEW operations will fail ...... this
is OK because REBIND will work.

FORCERENEW / RECONFIGURE messages won't work for similar reasons.

dhcpcd does try and work this out though so it may be ok.

Roy