dhcpcd now in dfly - disabled by default, tests needed
roy at marples.name
Thu Aug 1 03:09:14 PDT 2019
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).
>> 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
>> 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
>> 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
>> 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).
More information about the Users