dhcpcd now in dfly - disabled by default, tests needed

[Roy Marples]

Hi Aaron

On 01/08/2019 06:22, Aaron LI wrote:
> On August 1, 2019 11:48:58 AM GMT+08:00, Roy Marples <roy at marples.name> wrote:
> Thank you for creating the great dhcpcd software (and openresolve).

Pleasure :)

>> I'm upstream for dhcpcd and I just noticed that Dragonfly BSD imported
>> dhcpcd-7.0.8 about 9 months ago seemingly with the intent to make it
>> the
>> default DHCP and/or SLAAC client. This seems to have stalled.
> 
> Yes, I imported dhcpcd into DFly for the better IPv6 experience. The intention is to replace the dhclient and rtsold, but I haven't found enough time to finish the transition yet. More tests and some significant cleanups to the rc scripts are required. I think I'll have more time to continue the work in about two months. (By the way, I'm still working on updating the RC scripts w.r.t. freebsd and need to finish this first.)

So DFly has the same devd.conf that FBSD has.
You've also elected to integrate dhcpcd via the ifconfig_$if=DHCP directive.

I would argue that both methods should be purged - at least from user 
documentation. You might want to keep them for upgrades.

dhcpcd is designed to be single instance and supportive of plugable 
interfaces. The rationale is simple - if a laptop has both wireless and 
wired on the same subnet (which is quite common) only one interface can 
have the subnet route. If many instances of dhcpcd are started here, 
they will compete over the subnet route, whereas the single instance 
will manage it - preferring wired over wireless. So it's also 
deterministic rather than first come, first served.

The other situation is that of IP address sharing with the same scenario 
which has the same issue as described above, but it's a lot less common. 
Also, kernel changes would be needed for IPv6 address sharing, which is 
even more rare.

You can control dhcpcd per interface with allow/denyinterfaces directive 
in /etc/dhcpcd.conf. This works extremely well and gives the same 
functionality, but does seperate control from rc.conf which some may 
dislike.
  >> I've just released dhcpcd-8.0.2 which now has DragonFly support
>> upstreamed (basically a vlan header difference) and I'm now wondering
>> how I can progress making dhcpcd the default here?
> 
> Awesome! I noticed that you released new versions and intended to update ours. It's really great that you provide us with better support.
> 
>> I've had a quick look over the mailing lists and bugtracker, but I
>> don't
>> see anything that should have stalled this.
> 
> It's on my todo list ;). There shouldn't be anything to prevent this transition.

And there was me thinking that the kernel and header changes to make the 
warning messages dhcpcd logs during compile disappear would be the blockers.

For example using CMSG_LEN should not comlain about signed vs unsigned 
and the support of SIOCGIFALIAS would save a lot of CPU cycles working 
out if RTM_DELADDR matches reality (for example, the message could be 
delayed or in FreeBSD's case out-right lying).

Roy