Re: dhcpcd(8) into FreeBSD base

[Karl Denninger]

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.



Ronald.

*Van:* Karl Denninger <k...@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
    k...@denninger.net
    /The Market Ticker/
    /[S/MIME encrypted email preferred]/

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.

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

smime.p7s
Description: S/MIME Cryptographic Signature