Re: dhcpcd(8) into FreeBSD base

On 6/19/2025 04:21, Ronald Klop wrote:
> Hi,
>
> I don't know the details about your setup, but I tried dhcpcd in my 
> network last few months and I encountered that it:
>
> - runs fine in a 14.X jail on a 14.X machine (RPI3B) for both IP4 and 
> IP6 👍
> - it does not work well on a 14.X jail on a 15.x machines. (RPI4)
>
> The symptoms look a lot like what you describe. Sometimes it got an 
> address and a day later it was gone again. Restarting sometimes 
> helped, often didn't change anything.
> Up to the point that I started reading to code of dhcpcd and 
> encountered that it writes a line in the log about getting a lease and 
> the next statement was sending a packet out on the network and I never 
> see that packet in tcpdump.
>
> Anyway on the RPI3 I still use it. On the RPI4 I went back to dhclient 
> + SLAAC after I put a lot of time in tcpdumping and testing. Maybe it 
> is just that 14 userland doesn't match enough with 15 kernel to do 
> BPF/dhcp. But than again.... with dhclient it works fine.
>
> I didn't run dhcpcd yet on the host OS yet as I was first testing it 
> in the VNET jails.
>
> Just my 2 cents.
>
> Regards,
> Ronald.

The issue I have here is that when the other end gets "big mad" I have 
to call them to restore IPv6.  Before dhcpcd I was running both built-in 
DHCP from FreeBSD and dhcp6c to get the IPv6 stuff and had been for a 
very long time.  The complexity there is that I need to do things when 
an address is bound (or lost) and that gets considerably more-complex 
with using the two daemons rather than the one.

I can try to go back to the other setup but if it gets big mad at me 
again then I get to call them again.... :-)  Since it never clears on 
its own once it happens this is especially vexing in terms of figuring 
out precisely what is going on.

I have a suspicion that it is the ip4ll option and a slow response that 
may be involved here (and ip4ll defaults /on, /which might be a very 
poor choice), and perhaps not "technically" the ISPs fault in that its 
entirely possible their ONT comes ready on the customer-side interface 
(thus the gateway thinks the line is up) before the fiber-side has 
completed ranging and thus it is not entirely up and provisioned.  In 
that case dhcpcd is going to send a request that goes into a black hole 
and, having gotten no reply within a couple of seconds it does the ip4ll 
thing.

If THAT is what's making it mad (its seeing reserved address packets 
that are never routable coming from me) then my turning it off may fix 
it, but I don't know.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/