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 k...@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
