Date: Mon, 15 Aug 2022 07:50:13 +0200 From: Franco Fichtner <franco@opnsense.org> To: Roy Marples <roy@marples.name> Cc: Ben Woods <woodsb02@FreeBSD.org>, FreeBSD Net <freebsd-net@freebsd.org>, emaste@freebsd.org, Hiroki Sato <hrs@freebsd.org>, brooks@freebsd.org, cy@freebsd.org, Philip Paeps <philip@freebsd.org> Subject: Re: Import dhcpcd(8) into FreeBSD base Message-ID: <65A9F183-09B0-4A70-BE8B-CED050076380@opnsense.org> In-Reply-To: <636ed93d-57d1-0a26-1d8c-9fc0a55cece0@marples.name> References: <e401671f-6a67-49ed-bc41-e8fbb9de27cb@www.fastmail.com> <9831CA1D-1AE2-4B46-A781-D6B98BECDFBA@opnsense.org> <636ed93d-57d1-0a26-1d8c-9fc0a55cece0@marples.name>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Roy, I appreciate your answers. More inline below. > On 8. Aug 2022, at 12:42, Roy Marples <roy@marples.name> wrote: >=20 > Both dhclient and rtsold are only activated manually. > For dhclient there is an exponential backoff after each message is = sent. If the messages go nowhere (ie LINK_STATE_DOWN) then this delays = the configuration aquisition and can slow down the boot process. > For rtsold this is actually quite tricky as it requires a working LL = address before it can work. > This leads to sleep commands in rc which results in a slower than = optimal boot time. While there are true they do pertain to RC integration in FreeBSD. I = know because other projects have improved the situation with the tools at hand. > dhcpcd reacts to state changes - however FreeBSD does not announce all = state changes needed for this. For example here is a changeset I made 6 = years ago for FreeBSD which allows this IPv6 addresses to announce state = transitions from TENTATIVE to non TENTATIVE/DUPLICATED here: > https://reviews.freebsd.org/D5469 Yes, this would be nice to have user space access to. :) > Any DHCPv6 client also needs either a sleep or the above state changes = to be made available. I agree there is no canonical way to watch for changes, especially for = scripting duty around SLAAC. > There is a swathe of DHCP related RFC's that dhclient does not = support, although none are necessary to actually get a working = configuration for most users. That could be. 6RD through DHCP is tricky for example. But on the other = hand we do have a lot of people using routers and direct ISP connectivity and do encounter the most visible = issues here which in my opinion you cannot see from a home lab or traditional "network server" FreeBSD use case. > rtsold (in FreeBSD-13 at least) has no mechanism to get RDNSS and = DNSSL options from RA messages into the local nameserver. I may be mistaken, but the -R option should take care of this and seems = to be enabled by default invoking resolvconf(8). I think this has been the case for a number of major iterations before = FreeBSD 13. > dhclient and FreeBSD kernel RA handling do not support a predictable = configuration for multi-homed boxes. It operates on a first come, first = served basis. That's due to dhclient-script handling, sort of like the RC integration = issue mentioned before. > dhcpcd supports a predictable configuration allowing a "better" = interface to take over the default route, preferred nameservers, etc. That does sound nice for integration. Thanks for confirming.=20 > There's no proposal to remove dhclient or rtsold yet. To be fair, that was the original proposal. If dhclient and rtosold are = not removed and made second class citizens in FreeBSD that amounts to the same bitrot = and neglect that we would see if it would be taken out of the base system. Just my concerns here. I'm sure people will find a way. :) Cheers, Franco=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?65A9F183-09B0-4A70-BE8B-CED050076380>