Re: dhcpcd(8) into FreeBSD base

I've not seen anything like that; it appears that the issue I've had is 
related to my (very strong) desire to have the gateway be entirely 
power-fail safe, which in turn means that the contents of /var/db are 
volatile (since its a nanobsd build.) //That, coupled with the ISPs 
original "valid" time for the Ip6 delegation being roughly a week means 
they from what they're telling is that they want me to attempt to rebind 
on a reboot (e.g. power loss, software upgrade, etc.) and of course you 
can't if you don't know what the original delegation was.  The same 
applies to the duid although dhcpcd does have a way to produce what 
should be invariant for at least a consistent MAC address (e.g. 
interface to which you're plugged.)

I'm wondering if the interaction you ran into is related to its use of BPF.

On 6/20/2025 09:43, Ronald Klop wrote:
>
> I have tried the "noip4ll" and "noarp" option. Didn't change anything.
>
> My issue ended up that dhcpcd said in the logs it would sent a dhcp 
> packet (the port 67/68 thing), but nothing appeared on the network. 
> And so the lease timed out after a long time and it removed the IP 
> address from the interface.
>
> Ronald.
>
> *Van:* Karl Denninger <karl@denninger.net>
> *Datum:*vrijdag, 20 juni 2025 15:24
> *Aan:*freebsd-net@freebsd.org
> *Onderwerp:*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.
>
>     Now that's very curious.
>
>     Could you (where you can control what's going on with the other
>     end, which I can't) try again with "noip4ll" and "noarp" and see
>     if you still get the oddness?
>
>     I have a suspicion this is the cause (from the docs "noarp" should
>     be enough to disable both, but never hurts to stick 'em both in
>     there) -- and if so then perhaps default behavior should be changed.
>
>     --
>     Karl Denninger
>     karl@denninger.net
>     /The Market Ticker/
>     /[S/MIME encrypted email preferred]/
>
>
-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/